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ADVANCED  MULTIPLE  PROCESSOR 
CONFIGURATION  STUDY 


I.  INTRODUCTION 


1.1  Scope 

This  document  constitutes  the  Final  Report  for  the  Advanced  Multiple  Processor  Configuration  Study 
performed  by  Teledyne  Brown  Engineering  (TBE)  under  Contract  Fd3()lS-7*f-C-0003  for  the  Air  Force 
Human  Resources  Laboratory  (AFHRL).  This  first  section  provides  an  introduction  and  an  executive 
summary  of  the  study  in  terms  of  objectives,  background,  approach  and  findings.  Section  2  highlights  the 
literature  search  and  simulator  analysis  which  led  to  the  resultant  design  goals  for  the  multiple  processor 
performance  prediction  evaluation  model  presented  in  Section  3.  Section  4  presents  detailed  design  and 
implementation  recommendations  for  automated  tools  with  respect  to  evaluation  of  alternative  candidate 
multiple  processor  configurations  for  flight  training  simulators.  The  concluding  remarks  of  Section  5 
summarize  this  study  and  list  areas  for  further  study. 

1 .2  Objectives 

The  major  objective  of  this  study  was  to  provide  the  Air  Force  with  techniques  for  determining  the 
effect  of  alternative  multiple  processor  configurations  on  training  simulator  performance.  The  techniques 
sought  and  addressed  herein  are  applicable  to  both  the  optimal  design  process  and  the  competitive  design 
evaluation  of  simulator  computational  candidate  configurations  which  may  include  mixtures  of  medium, 
mini-,  and  micro-computers  and  processors.  For  purposes  of  this  contract,  the  term  multiple  processor 
configuration  was  defined  to  he  any  computational  configuration  containing  more  than  one  processor  in 
which  each  processor  is  required  to  communicate  (directly  or  via  shared  memory)  with  at  least  one  other 
processor  in  the  configuration  in  order  to  perform  and  coordinate  its  part  of  the  real-time  application. 

1.3  Background 

Increased  utilization  of  multiple  processor  configurations  and  the  proliferation  of  mini-  and  micro- 
based  processor  capahilities/capacities  permits  a  large  number  of  alternative  design  configurations. 
Benefits  of  such  designs  include  parallel  processing,  increased  iteration  rates,  off-loading  of  specialized 
tasks,  and  integration  with  selected  oii-hoard  avionics  processing  devices  for  flight  simulation 
applications.  However,  automated  techniques  for  measuring  performance  and  efficiency  tradeoffs  among 
many  alternative  design  configuration  were  not  available  to  the  Air  Force. 

As  a  result,  this  study  was  embarked  upon  to  provide  the  Air  Force  with  a  generalized  model  of 
computer  processor  combinations  from  which  flight  training  simulator  computational  candidate  designs 
can  be  evaluated. 

1.4  Approach 

An  analysis  of  real-time  flight  simulation  was  performed.  This  analysis  produced  a  set  of  design 
characteristics  in  terms  of  (a)  flight  simulator  configurations  and  (b)  multiple  processor  configuration 
performance  measures.  To  support  this  analysis,  a  literature  search  was  conducted  and  documented  to 
provide  state-of-the-art  assessment  of  multiple  processor  performance  evaluation  tools  and  techniques. 
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The  results  of  this  analysis  are  documented  in  Section  2  of  this  report.  These  results  include  recommended 
configuration  considerations  for  flight  simulator  computational  environments. 

The  analy  sis  laid  the  foundation  for  a  set  of  multiple  processor  design  evaluation  goals.  These  design 
goals  were  then  expanded  in  terms  of  outputs,  inputs,  and  model  processes  necessary  to  facilitate 
evaluation  of  various  configurations  of  multiple  processors.  The  design  goals  and  model  feasibility  are 
described  in  Section  3  of  this  report.  The  model  design  is  described  in  Section  4. 

1.5  Results 

TBE  has  identified  a  baseline  set  of  techniques  and  tools  which  can  provide  for  a  systematic 
evaluation  of  alternative  candidate  multiple  processor  designs  with  respect  to  a  set  of  quantitative 
computational  measures  for  a  given  application.  Implementation  of  these  techniques  for  simulator  design 
evaluation  is  enumerated  in  Section  4  of  this  report.  As  with  any  tool  or  technique,  the  skill  of  the 
personnel  using  them  and  the  availability  of  data  are  key  issues  in  selecting  and  implementing  them  as 
part  of  a  standard  evaluation  procedure. 

It  is  also  important  to  note  that  computational  design  performance  is  just  one  area  of  flight  training 
candidate  design  evaluation.  The  evaluation  of  new  algorithms  and  special-purpose  equipment  to  meet 
training  configuration  requirements  generally  requires  some  level  of  prototype  implementation  to 
properly  assess  human  factors. 

2.  FLIGHT  SIMULATOR  ANALYSIS 

2. 1  Literature  Search 

In  order  to  provide  a  relevant  set  of  flight  simulator  candidate  design  evaluation  techniques.  TBE 
performed  a  literature  search  to  collect  data  on  current  trainer  computational  configurations  and  generic 
multiple  processor  real-time  performance  features.  Figure  1  illustrates  the  key  word  form  utilized  to 
search  for  and  characterize  the  collected  articles  for  detailed  analysis. 

Specific  flight  simulator  configuration  materials  were  collected  from  both  military  and  commercial 
organizations.  Initial  compilation  of  a  list  of  flight  simulator  facilities  (tabulated  in  Table  1)  was  derived 
from  analysis  of  several  key  simulator  facility  survey  articles  (References  1.  2.  3).  These  facilities  (Table 
1)  were  then  contacted  (via  phone)  to  obtain  up-to-date  configurations  data  with  respect  to  the  following 
items: 

1.  Aircraft  modeled 

2.  Training/engineering  positions 

3.  Computational  configuration  to  include  processors,  memories,  mass  storage,  and  development 
language 

4.  Special-purpose  subsystem  peripherals  to  include  visual  imagery,  motion  base,  “g"  queuing, 
instructor  station,  and  training  station  equipment  features. 

Most  of  the  military-related  organizations  contacted  sent  facility  capability  brochures.  These  brochures 
provided  high-level  descriptions  of  the  computational  configuration. 
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Table  l.  List  of  Facilities  Contacted 


Facility 

Point  of  Contact 

Facility 

Point  of  Contact 

ASPT 

AFHRL  Flying  Training  Division  (AFSC) 

FSAA 

NASA/AMES 

Williams  Air  Force  Base,  AZ 

Moffett  Field,  CA 

A7-E  NUT 

T.D.C. 

F-15A 

Goodyear  Aerospace  Corporation 

Cecil  Field,  NAS.  FL 

Akron,  OH 

Boeing  707 

Boeing  Commercial  Airplane  Company 

Lambs 

Vought  Aeronautics  Co. 

Seattle.  WA 

Dallas,  TX 

Boeing  727 

American  Airlines 

LAS/WAVS 

Northrop  Corporation 

F(.  Worth,  TX 

Hawthorne,  CA 

727 

Continental  Airlines 

MACS.  !,  11.  Ill 

McDonnell  Douglas  Corporation 

Ix>s  Angeles.  CA 

St.  Louis.  MO 

Boe»ng  727 — 200 

Braniff  International 

MACS-Device  2E6 

McDonnell  Douglas 

Dallas,  TX 

St.  Louis.  MO 

Boeing  737 

United  Airlines 

P-.1C. 

NAS/Moffell  Field.  CA 

Denver,  CO 

S-3A  W  ST 

T.D.C 

DC-8  Instrument 

Flying  Tiger  Airlines 

NAS/Cecil  Field.  FA 

Flight  Sim. 

Los  Angeles,  CA 

S-61  VMS 

N ASA/1.ANCLEY  Research  Center. 
VA 

DC-8 

Braniff  International 

Dallas,  TX 

SAAC 

l.uke  AFB.  AZ 

DC-10 

American  Airlines 

Ft.  Worth,  TX 

SH-2F  HWST 

NAS/Norfolk.  VA 

DC-10 

Flight  Safety  International 

TA-4J 

NAS/Chase  Field 

1/ong  Beach.  CA 

Beeville.  TX 

Differential 
Maneuvering  Sim. 

NASA/Langley  Research  Center.  VA 

T-20 

Same  as  above 

F-lt 

TD  1 

VACS 

Vought  Corporation 

HAS/Miramar,  CA 

Grand  Prairie.  TX 

In  addition  to  the  specific  flight  simulator  configuration  materials,  we  collected  general  materials 
regarding  selection,  design,  and  performance  evaluation  of  multiple  processor  configurations  for  real¬ 
time  application  processing  needs  versus  utilization  of  processing  features  unique  to  given  candidate 
hardware  configurations.  The  majority  of  articles  which  relate  to  performance  prediction  topics  tend  to 
come  from  professional  technical  journals  and  proceedings  such  as  AIAA,  ACM,  IEEE,  and  others. 

The  resulting  analysis  of  current  flight  simulator  configurations  is  presented  in  Section  2.2  and  2.3. 
This  is  followed  by  the  generalized  analysis  of  real-time  application  multiple  processor  performance 
features,  design  goals,  and  performance  evaluation  modeling  techniques  which  are  presented  in  Section  3. 


2.2  Computational  Interfaces 


Flight  simulator  facilities  may  be  categorized  into  three  distinct  operational  environments;  namely, 
airframe  research/development,  training  research/development,  and  training  simulator  devices.  This 
contract  was  primarily  concerned  with  the  hardware  configuration  features  which  are  required  to  satisfy 
and  support  the  computational  aspects  of  the  real-time  operational  flight  training  simulator  device 
environment. 

In  order  to  fully  appreciate  the  computational  hardware  configurations,  one  must  first  consider  the 
major  external  interfaces  which  are  serviced.  At  the  highest  level,  the  flight  training  device  configuration 
must  coordinate  and  respond  to  "man-in-the-loop”  directives  and  responses.  Figure  2  depicts  the  generic 
manual  interfaces  as  trainees,  instructor/operators,  system  development  analysts,  and  operational 
maintenance  analysts.  The  manual  procedures  are  not  within  the  scope  of  this  contract;  thus,  emphasis  is 
placed  upon  the  hardware/software  systems  discrete  interfaces  with  man  which  can  be  parametrically  and 
quantitatively  defined. 


Figure  2.  Generic  “man-in-the-loop"  interfaces 
with  a  flight  training  simulator. 

It  should  be  noted  that  the  categories  of  manual  interfaces  have  been  selected  with  respect  to  major 
functional  interfaces.  An  individual  may  interact  with  the  system  in  one  or  more  roles.  For  example,  a 
system  developer  can  submit  a  test  execution  of  a  new  or  modified  capability  which  requires  inputs  from 
instructor/operator  stations  and/or  training  position  devices.  To  expedite  initial  checkout  in  the  test 
environment,  system  developers  may  “act”  as  instrurtor(s)  and/or  trainee(s)  to  test  these  interfaces.  A 
trainee  in  the  self-instruction  mode  will  utilize  instructor/operator  controls  (as  well  as  the  training  station 
equipment)  to  select  training  exercises  and  obtain  performance  evaluation  reports.  An  instructor  may 
“act”  in  a  trainee  role  to  test,  record,  and  evaluate  the  simulation  system  responses  to  the  training  position 
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controls.  In  summation,  the  system  must  accommodate  and  supply  the  basic  tools  and  interfaces  by  which 
trainees,  instructor/operators,  maintenance  operators,  and  developers  can  interact.  To  place  the  current 
configuration  analysis  in  proper  perspective,  each  of  these  “man-in-the-loop"  interfaces  is  briefly- 
expanded. 

2.2.1  Trainee  Positions.  The  trainee  positions  supported  by  a  training  simulator  configuration 
(TRANEE  of  Figure  2)  may  be  as  simple  as  one  pilot  to  the  complexity  of  flight  crews  for  multiple  aircraft 
systems.  For  purposes  of  this  analysis,  training  positions  have  been  categorized  to  include  pilots,  co-pilots, 
on-board  computer  operators,  on-board  weapon  system  operators,  or  any  combinational  positions  which 
require  manual  interaction  in  the  real-world  system  being  simulated.  Each  distinct  trainee  position  has  a 
finite  number  of  controls,  dials,  and  switches  which  provide  real-time  inputs  to  the  computational 
configuration.  These  inputs  are  monitored  at  prescribed  frequencies  by  the  computational  subsystem 
which,  in  turn,  must  output  a  realistic  simulated  environment  to  include  instrument  readings,  on-board 
displays,  motion,  gravitational  forces,  visual,  audio,  navigation,  and  communication  responses. 

2.2.2  Instructor/Oiierators.  An  instructor/operator  (INSTOP  of  Figure  2)  interface  with  the  existing 
simulation  facility  is  to  conduct,  monitor,  and  evaluate  training.  In  the  generic  system,  independent 
simultaneous  training  sessions  may  be  taking  place.  Each  one  may  use  one  or  more  instructors  and/or 
operators.  These  operational  input  interfaces  have  been  categorized  in  the  following  groups: 

1.  Initialization  for  a  specific  training  configuration 

2.  Change  mode  of  training  job  (real-time  state,  scenario  record/playback,  etc.) 

3.  Display/update  training  data  base  parameters 

4.  Insert  malfunctions 

5.  Insert  weather  and  environment  data 

6.  Request  monitor  displays 

7.  Display  aircraft  indicators  on  instructor  panel 

8.  Request  performance  evaluation  report 

9.  Voice  transmit/receive/record. 

The  types  of  outputs  may  be  generically  categorized  as: 

1.  CRT/video/plotter  displays 

2.  Printer/teletype  summaries  and  listings 

3.  Instructor  panel  indicators,  lights,  and  warnings 

4.  Audio  communications. 

As  with  the  training  position  station,  an  instructor  station  will  consist  of  a  finite  set  of  entry  devices. 
The  flight  training  system  is  required  to  monitor  each  control/switch/keyed  entry  at  prescribed 
frequencies.  When  more  than  one  instructor  is  participating  in  a  training  session,  priorities  and  override 
interfaces  must  also  be  defined.  Resource  allocation  requirements  are  necessary  when  simultaneous 
independent  training  sessions  are  being  conducted  and  monitored  by  the  same  instructor  station. 

2.2.3  Maintenance  Operators.  Day-to-day  operations  include  routine  services  as  well  as 
troubleshooting  diagnostics  and  repairs  when  needed.  Routine  services  include  powering  the  system  up/ 
down,  mounting  tapes/discs/paper,  scheduling  job  entry  and  special  duties  associated  with  equipment 
readiness  and  preventive  maintenance.  When  system  problems  arise,  system  troubleshooting  procedures 
for  HW/SW  fault  isolation  are  performed.  Maintenance  HW/SW  features  must  be  an  integral  part  of 
system  performance  and  utility  evaluation  with  respect  to  anticipated  down  time,  maintenance  costs,  and 
support  software/hardware  resources. 

2.2.4  System  Developers.  The  training  simulator  configuration  must  be  amenable  to  inevitable 
changes  in  aircraft  configuration  and/or  procedural  changes  introduced  during  its  operational  life  cycle. 


To  do  this,  system  development/maintenance  personnel  must  be  provided  appropriate  interfaces  for 
introducing,  testing,  and  incorporating  new/changed  modules/subsystems  in  areas  of  software  and 
hardware.  These  interfaces  with  the  computational  subsystem  must  be  performed  in  accordance  with 
established  configuration  management/quality  assurance  controls  to  assure  maintenance  of  an 
operationally  ready  training  facility. 


2.3  Computational  Configuration  Features 

To  provide  responsive  real-time  interaction  with  the  interfaces  described  in  Section  2.2,  the  simulator 
configurations  studied  employ  multiple  processors  to  handle  the  real-time  process  load.  In  general,  no 
single  processor  currently  exists  with  the  capacity  to  handle  all  advanced  training  simulation 
computational  needs.  The  numerous  alternatives  for  hardware  selection,  interfacing  devices,  and  process/ 
storage  partitioning  provide  a  complex  maze  of  configuration  design  evaluation  decisions. 

Certain  common  computational  design  features  were  extracted  during  the  analysis  of  flight  simulator 
designs.  Those  configuration  features  identified  include: 

1.  Operational  Real-Time  Command.  Control,  and  Communication  (C3) 

2.  Diversified  I/O 

3.  Math  Model  Arithmetic  Precision.  Accuracy,  and  Stability 

4.  Sufficient  System  Spare  Capacity  and  Growth  Provisions 

5.  Reliable  and  Proven  Hardware 

6.  Development  and  Diagnostic  Support 

Each  of  these  factures  is  now  expanded  in  terms  of: 

1.  Related  real-time  computational  environment  needs 

2.  Applicable  statements  extracted  from  USAF  Military  Specification  (M1L-D-83468)  Digital 
Computational  System  for  Real-Time  Training  Simulators 

3.  Observed  implementation  characteristics  in  current  flight  simulator  configurations. 

The  relationships  of  these  features  to  performance  prediction  measurement  is  given  in  Section  3. 

2.3.1  Operational  Real-Time  Command ,  Control,  and  Communications  (C3).  The  success  or 
failure  of  a  given  multiple  processor  configuration  relates  to  the  ease  with  which  it  adapts  to  a  variety  of 
flexible  training  configurations.  Figure  3  illustrates  major  functional  areas  which  must  be  coordinated  by 
a  real-time  flight  training  simulator  executive  program.  This  real-time  customed  executive  program 
coordinates  the  functional  module  execution  rates  and  data  transfers  for  a  given  training  job.  With  the 
exception  of  the  initialization  interfaces,  these  functions  require  high  iteration  rates  with  complex  real¬ 
time  data  base  update  coordination  to  produce  a  conducive  training  environment  for  all  participants. 

In  general,  the  more  training  and  instructor  station  positions  supported,  the  more  complex  the 
enumeration  of  potential  training  configuration  and  required  C3  synchronization  becomes.  A  multiple 
processor  network  configuration  for  flight  training  simulators  must  have  real-time  operational  features 
which  support  control  of  the  current  training  mix  via  straightforward  user  interface  commands  which  are 
properly  communicated  in  terms  of  resource  sharing,  task  iteration  and  sequencing,  and  peripheral  device 
I/O  servicing.  When  multiple  independent  training  sessions  are  permitted,  a  means  for  system  resource 
sharing,  as  well  as  a  given  training  job  resource  sharing,  is  necessary  in  terms  of  multi-tasking,  data  base 
retrieval,  processor  assignments,  memory  management,  processor-to-processor  communications,  and 
peripheral  device  assignments. 
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Figure  .3.  Real-time  executive  must  coordinate  all 
task  and  data  flow  for  given  functional  areas. 


MIL-D-8M468  (I'SAF)  states  the  following  regarding  operational  control: 

"IVl.1.1  Mulliproceswr/multicomputer  configuration.  If 
a  mulliproreSHor/multicompulpr  configuration  is  proposed 
to  meet  the  operational  requirements  of  the  trainer,  the 
following  requirements  shall  apply  to  each  computer  in 
the  system.  Multiprocessor/multicomputer  configurations 
shall  be  designed  such  that  all  computers  operate  in 
parallel  in  real-time  and  are  controlled  and  time 
synchronized  from  a  single  computer  program  supervisor/ 
executive.  This  supervisor/executive  shall  direct  the 
problem  flow  and  establish  priority  controls." 

In  the  past,  many  of  the  control  functions  have  traditionally  been  handled  via  a  custom-tailored,  real-time 
flight  training  simulator  executive  driven  by  hardcoded  software  structures  which  limited  themselves  to  a 
predefined  set  of  training  configurations  and  resulted  in  hard-to-reconfigure  designs.  The  current  design 
trends  are  toward  more  modular  executive  structures  which  are  device  and  processor  independent.  Still, 
the  real-time  constraints  are  very  demanding,  requiring  a  means  of  streamlining  executive 
communication  and  controls.  As  a  result,  the  basic  vendor-supplied  real-time  operating  systems  have  been 
expanded  to  incorporate  many  of  the  previously  defined  executive  functions,  permitting  the  actual 
executive  to  be  constructed  as  a  series  of  macros  which  contain  C3  parameters  in  generic  form  to  support  a 
more  flexible  system  executive  environment.  This  flexibility  does  reduce  the  ratio  of  application  code  to 
system  supplied  code. 
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2.3.2  Diversified  I/O.  A  flight  training  simulator  incorporates  a  variety  of  training  station  I/O 
devices  to  include  aircraft  controls,  switches,  instrumentation,  head-up  display:  weapon  system  controls, 
switches,  displays:  on-board  computers,  keyboards,  displays;  plus  simulated  out-the-window  scenes. 
motion,  "g"  forces,  sound  (aircraft,  engine,  weapons,  etc.),  and  radio  navigation  and  voice 
communication.  The  proper  coordination  of  these  components  is  a  function  of  the  training  maneuver(s) 
hing  performed  (air-to-air  combat,  air-to-surface  combat,  going  to  and  coming  from  mission,  takeoff  and 
landings)  and  the  conditions  being  simulated/recorded  (task  difficulty,  weather  conditions,  malfunctions, 
and  instructor  station  monitoring  and  scoring  features).  These  are  in  addition  to  standard  computer 
configuration  components  consisting  of  tapes,  discs,  operator  stations,  processors,  memories,  card  readers, 
printers,  and  CRT  terminals.  The  flight  training  simulator  candidate  configuration  must  satisfy  the 
diverse  I/O  requirements  including  A/D  sampling  input  rates,  D/A  response  output  rates,  and  digital 
communications  with  a  large  number  of  unique  devices. 

To  permit  maximum  training  configuration  flexibility,  MIL-D-83468  states  that  for  multiprocessor/ 
multicomputer  configurations: 

"Each  computer  shall  be  capable  of  directly 
communicating,  without  involving  other  central 
processing  units  (CPI's),  with  all  peripheral  equipment,  all 
instructor  station  systems  for  which  it  computes 
information  or  controls  information  flow,  and  all 
interfaces  for  which  it  computes  or  controls  information." 

Specific  input/output  capabilities  are  further  expanded  in  paragraphs  under  3.1.2  of  MIL-D-83468. 

The  means  for  accommodating  special-purpose  device  I/O  is  directly  related  to  the  application 
software  partitioning  problem.  The  design  studied  included  two  major  approaches,  namely: 

1.  Partition  of  processors  into  functions  such  as  visual,  math  model,  instructional  aides  for  all 
training  stations  with  provision  for  high-speed  transfer  of  interfacing  data  blocked  by  postion 
hierarchy  structures. 

2.  Partition  of  processors  into  self-contained  groups  supporting  all  functions  for  a  given  training/ 
instructor  station  and  provisions  for  high-speed  data  transfers  when  interactive  (one-on-one. 
two-on-one.  etc.)  training  positions  must  be  correlated. 

Of  the  configurations  studied,  the  interactive  capabilities  were  limited  to  one-on-one  and  two-on-one 
combat/formation  maneuvers.  Physical  processing  timing/sizing  problems  are  apt  to  occur  for  either  of 
the  above  partitioning  schemes  when  more  than  three  interactive  aircrews  are  being  trained.  Thus,  a 
communication  matrix  network  is  needed  to  provide  both  functional  and/or  positional  related  data.  The 
partitioning  tradeoffs  are  numerous  in  themselves  and  were  the  subject  of  a  related  report  (Reference  7). 
For  purposes  of  evaluating  multiple  processor  performance,  the  software  partition  is  assumed  to  be  well- 
defined  in  terms  of  the  candidate  configuration.  Thus,  the  major  concern  becomes  one  of  ensuring  that  all 
the  special-purpose  I/O  devices  are  being  serviced  in  a  timely  and  proper  fashion.  Another  I/O  issue 
concerns  degraded  mode  alternatives  for  reconfiguring  the  processor  loads  and/or  memory  storage 
interfaces  to  service  given  peripherals  when  a  processor  and/or  memory  unit  must  be  taken  off-line. 
Further  study  of  this  area  is  recommended. 

2.3.3  Math  Model  Arithmetic  Precision,  Accuracy,  and  Stability.  The  numerical  precision  (numbei 
of  significant  digits)  and  accuracy  (units)  is  a  vital  part  of  the  simulated  aircraft  models  which  incorporate 
preset  flight  data  and  device  biases  for  real-time  response  calculations  based  on  trainee  control  inputs. 
Farly  versions  of  digitally  driven  simulators  employed  fixed  binary  arithmetic  making  it  the  coder's 
responsibility  to  keep  track  of  scaling  and  accuracy  for  all  arithmetic  operations.  As  floating  point 
hardware  proved  itself  to  be  adequate  with  respect  to  both  timing  and  accuracy,  the  mathematical  models 


have  been  redesigned  for  use  with  floating  point.  Reference  4  is  a  dissertation  which  specifically  addresses 
the  cost-effectiveness  of  floating  point  hardware  operations  with  respect  to  the  real-time  simulation 
problem.  Since  this  publication,  significant  improvements  have  been  made  which  make  floating  point 
hardware  even  more  advantageous  along  with  lower  hardware  costs.  One  of  the  major  cost-effective 
reasons  pertains  to  the  decreased  number  of  instructions  which  must  be  coded/debugged/maintained  for  a 
given  real-time  simulation. 

MIL-D-83468  outlines  areas  of  numerical  stability  and  accuracy  which  must  be  analyzed  with  respect 
to  the  dynamics  of  the  problem  plus  specific  processor  truncation,  roundoff,  and  propagated  errors.  These 
areas  include  numeric  integration  techniques,  intervals,  and  interation  frequency  of  associated  I/O 
parameters  utilized  by  the  various  integration  models.  This  specification  also  requires  any  floating  point 
operations  be  performed  via  floating  point  hardware  as  opposed  to  softcoded  equivalents. 

Current  utilization  of  a  fixed  word  length  machine  with  byte,  half-word,  full-word,  and  double-word 
data  structure  characterization  permits  a  variety  of  data  operations  in  both  fixed  and  floating  point 
instruction  sets.  The  precision  and  accuracy  features  for  incorporating  these  flexible  structures  must  be 
addressed  as  a  design  issue  in  terms  of  what  particular  precision  (number  of  significant  digits)  is  required 
to  satisfy  computational  relationships  for  the  desired  accuracy  (units).  In  some  instances,  the  automatic 
assumption  that  floating  point  is  adequate  may  lead  to  unstable  numeric  conditions  if  some  scaling 
analysis  has  not  been  performed.  This  is  due  to  the  gross  discontinuities  when  operating  on  additive 
floating  point  parameters  which  have  a  substantial  range  in  order  to  magnitude.  In  addition,  the  trend  in 
higher-order  language  specifications  is  one  of  specifying  the  required  precision  and  accuracy  as  opposed 
to  using  default  word  size  of  a  given  target  machine.  Significant  increased  speeds  of  future  hardware  logic 
may  make  floating  point  binary  coded  decimal  with  automatic  machine  scaling  arithmetic  logic  units  a 
future  consideration.  In  essence,  the  task  data  base  design  must  evolve  from  a  numerical  analysis  of  the 
parameters  and  the  intermediate  relationships  of  the  calculations  necessary  to  obtain  system  responses 
which  are  maintained  in  a  certain  precision  to  guarantee  a  minimum  level  of  accuracy.  Thus,  the  selection 
of  processors  and  memories  becomes  one  of  matching  arithmetic  features  with  required  design  arithmetic 
features  for  each  of  the  various  functional  tasks. 

Current  simulator  designs  show  a  trend  toward  use  of  32-bit  floating  point  operands  as  opposed  to 
earlier  (1960's)  designs  which  were  16-bit  fixed  point.  They  also  employ  a  varied  range  of  iteration  rates. 
This  has  resulted  in  a  combination  of  increased  hardware  real-time  capabilities  and  extensive  operational 
R&D  test  bed  "fly-offs”  among  various  math  model  computational  algorithms. 

2.3.4  Sufficient  System  Spare  Capacity  and  Growth  Provisions.  The  real-time  computational  tasks 
have  a  mixture  of  memory,  processor/peripheral  iterface  needs.  Memory  storage  is  required  in  the 
following  categories: 

1.  Preset  tables  of  flight  data  for  real-time  parameter  interpolation  for  each  aircraft  or  weapon 
system  being  modeled 

2.  Training  device  bias  value  tables  to  compensate  for  system  calibration  idiosyncrasies 

3.  Shared  block  of  intermediate  simulated  state  data 

4.  Instruction  storage 

5.  Temporary  computational  storage. 

The  real-time  processing  cycle  is  generally  characterized  as  a  set  of  tasks  with  prescribed  iteration  rates, 
sequencing,  and  data  dependencies.  Thus  certain  tasks  are  permitted  to  execute  in  parallel  whereas  others 
must  be  serially  sequenced  in  the  allotted  real-time  cycle.  As  more  training  capabilities  are  added,  more 
system  resource  are  needed.  This  is  especially  true  when  additional  trainin  device  stations  are  added  to  the 
configuration.  The  candidate  configuration  memory  parameters  must  properly  relate  private  and/or 
shared  memory  capabilities  with  respect  to  processor  and  peripheral  device  communication  buffers. 
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Shared  memory  is  generally  organized  around  a  multiport  controller  which  allows  a  specific  port 
assignment  for  given  CPU  access  to  the  common  data  base  and  system  status  information. 

A  critical  part  of  any  candidate  design  configuration  is  the  provision  for  spare  capacity  within  each 
individual  processor,  memory  mass  storage,  or  I/O  interface  unit.  MIL-D-83468  paragraph  3.1.6  addresses 
specific  measures,  spare  processor,  memory,  on-line  mass  storage,  and  I/O  channel  interface  capacity. 
Spare  growth  capability  measures  are  described  in  paragraph  3.1.7  of  this  MU.  SPEC.  Currently  100% 
expansion  capability  is  required  in  the  areas  of  directly  addressable  memory,  mass  storage,  processing 
capacity,  and  input/output.  In  addition,  the  growth  capability  must  be  achievable  with  minimal  design 
changes  to  existing  hardware/software  and  equipment. 

To  account  for  spare  rapacity  and  configuration  growth,  the  computational  real-time  cycle  tasks  are 
allocated  via  a  storage  and  timing  budget.  These  budgets  should  incorporate  the  task  iteration  rate,  data 
dependencies,  processing  dependencies,  and  communication  interfaces.  However,  in  many  of  the 
observed  design  documents  these  numbers  were  represented  as  aggregate  totals  including  system 
overhead  rather  than  at  the  task  level.  In  most  cases,  these  budget  grow  larger  as  design  and 
implementation  details  become  known.  This  is  another  major  reason  for  building  in  large  spare  and 
growth  factors  in  the  conceptual  and  preliminary  design  phases.  It  also  supports  the  theory  of  refining  the 
software  design  prior  to  a  final  commitment  to  specific  computational  equipment  and  internal 
configuration  interface  selection.  One  Air  Force  evaluator  expressed  a  major  need  in  this  area  for  better 
tools  and  techniques  to  help  determine  if  proposed  configurations  are  adequate  and,  also,  to  evaluate 
major  change  proposals  to  add  processors  and/or  memories  when  the  revised  budgets  indicate  spare 
capacity  or  growth  violations. 

Another  feature  which  relates  to  spare/growth  configuration  design  concerns  task  partitioning 
problem.  For  example,  if  multiple  duplicate  aircraft  models  are  involved  in  the  training  sortie,  then 
certain  common  blocks  of  aircraft  data  are  needed  to  support  computations  for  the  duplicate  training 
positions.  In  addition,  a  training  position  current  state  block  will  be  needed  for  each  of  the  duplicate 
training  positions.  These  current  state  blocks  are  most  likely  to  be  in  private  momories  associated  with  the 
specific  processor  performing  the  aircraft  model  computations  for  the  training  device  whereas  the  basic 
aircraft  model  data  will  most  likely  reside  in  a  shared  memory.  Thus  a  tradeoff  between  hardware/ 
software  design  solutions  must  be  made. 

2.3.5  Reliable  and  Proven  Hardware.  Operational  flight  training  requires  coordination  of  facility, 
instructor,  operator,  maintenance,  and  student  personnel  schedules.  Postponement  of  a  training  exercise 
due  to  equipment  failure  can  be  a  costly  rescheduling  problem,  particularly  in  a  temporary  duty  training 
environment  where  personnel  must  extend  their  TDY  assignment  or  reschedule  a  TDY  assignement  for  a 
later  date,  thus  impacting  other  duty  assignments  and  possibly  slipping  project  milestone 
accomplishments. 

Specific  availability,  maintainability,  and  reliability  requirements  are  specified  by  the  Air  Force  for  a 
given  simulator  procurement  in  terms  of  the  total  simulator  system.  For  example,  the  simulator  facility 
may  be  required  to  be  available  for  training  16  hours  per  day,  6  days  a  week  for  a  20-year  life  cycle. 

A  viable  multiple  processor  candidate  design  must  be  composed  of  proven,  reliable  components. 
Hardware  technology  has  made  significant  advancements  with  respect  to  component  preventive 
maintenance,  meantime  between  failure,  and  parts  replacement  schedules.  As  new  technologies  become 
available,  the  feature  of  reliable  and  proven  hardware  must  be  analyzed  for  a  given  design 
implementation  based  upon  laboratory  prototype  test  conditions  of  the  technology  components.  This  is 
necessary  to  reduce  the  amount  of  risk  associated, with  the  introduction  of  new  technologies  into  the 
operational  environment. 
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In  addition  to  individual  component  reliability,  the  total  system  must  be  viewed  from  a  master 
schedule  of  expected  operational  versus  maintenance  timelines  which  considers  the  net  effect  of  the 
various  component  schedules.  This  generally  entails  the  combining  of  prventive  maintenance,  parts 
replacement  schedules,  and  spare  supplies  to  consolidate  the  anticipated  system  downtime.  A  candidate 
design  must  include  the  anticipated  schedules  along  with  the  supporting  analysis  inputs  which  were  used 
to  derive  the  schedule.  One  problem  in  this  area  is  assuring  availability  of  spares  and  decisions  as  to  when 
to  upgrade  equipment  per  periodic  vendor  modifications/enhancements. 

The  govenment  typically  assumes  the  operational  system  maintenance  upon  acceptance  of  a  training 
simulator  device.  As  a  result,  many  logistic  problems  from  past  experience  are  now  required  to  be 
addressed  as  part  of  the  design  specification.  Use  of  built-in  test  equipment  (BITE)  and  built-in-test  (BIT) 
procedures  are  becoming  an  essential  design  feature  for  efficient  maintenance  of  advanced  computational 
subsystems.  Reference  5,  “Downtime  Wastes  the  Resources,”  provides  an  overview  of  the  logistics  support 
problems  and  their  impact  on  life-cycle  costs  (LCC). 

2.3.6  Development  and  Diagnostic  Support.  Development  of  a  new  training  simulator  device 
represents  a  major  investment  in  both  time  and  money.  An  essential  requirment  for  a  training  simulator 
device  is  that  it  be  representative  of  the  operational  device(s)  for  which  training  is  being  conducted. 
Operational  configurations  are  continuously  being  upgraded  to  meet  new  mission  requirements  and/or 
enhance  the  manual  operation  control  response  features.  Therefore,  the  training  simulator  device  must  be 
flexible  and  modular  in  design  to  permit  software/hardware  upgrades  in  a  timely/orderly  manner. 

Before  any  new  application/change  can  be  realized,  it  must  be  conceived,  specified,  designed,  built, 
and  successfully  tested.  A  number  of  software  tools  can  provide  a  systematic  means  for  carrying  out  the 
system  development  cycle.  Once  an  operational  capability  has  been  developed,  a  means  for  maintaining  it 
is  required.  Automated  maintenance  software  can  facilitate  systematic  procedures  for  configuring  the 
system  or  a  subsystem  required  to  support  specific  operational  real-time  training  jobs.  Figure  4  represents 
the  Flight  Trainer  Hardware  Software  (FTHS)  in  terms  of  the  above  defined  jobs  which  must  be 
coordinated  and  allocated  via  a  system  resource  manager  to  include: 

1.  Real-time  training  simulation  jobs 

2.  Development  jobs 

3.  Test  jobs 

4.  Maintenance  jobs. 

At  this  lime,  it  should  be  pointed  out  that  no  link  to  specific  hardware  configuration  has  been  made. 
The  development  tools  could  reside  on  a  separate  computer  system  which  formats  files  for  the  object 
system  where  actual  training  occurs;  or.  the  tools  could  reside  as  an  integral  part  of  a  multiprocessor 
system  for  development,  upgrading,  and  training. 

Section  3.2  of  MIL-D-83468  addresses  the  computer  program  system  components  and  features  which 
are  required  to  facilitate  total  simulator  operation,  maintenance,  training,  and  upgrade  configuration 
controls.  Emphasis  is  placed  on  a  top-down  design  incorporating  modules  which  can  be  identified  and 
handled  in  an  independent  manner.  Standard  vendor-supplied  support  programs  are  considered  to  be 
deliverables  including  the  resident  operating  system,  peripheral  operating/handler  systems,  loaders, 
assemblers,  compilers,  memory  dump  programs,  mathematical  library,  copy  routines,  and  trace  routines. 
In  addition,  a  full  set  of  maintenance  and  test  programs  are  to  be  supplied  including  computer  diagnostics, 
real-time  interface  equipment  diagnostics,  discrete  I/O  tests,  analog  I/O  tests,  program  control  test  of  real¬ 
time  clock,  simulator  equipment  check,  and  calibration  test  programs.  Where  possible,  standard  vendor- 
supplied  programs  are  to  be  utilized  for  these  functions  and  any  changes  must  be  justified. 
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Figure  4.  Generic  Job  Categories  include  the  real-time  simulator 
plus  support  aids  for  development,  testing,  and  maintenance 
of  system  upgrades  and  modifications. 


In  the  software  development  of  recent  simulators,  such  features  as  real-time  operating  systems, 
virtual  memory  management,  optimized  high-order  language  compilers,  instruction  set  hardware  options, 
and  data  base  management  utilities  have  reduced  the  amount  of  application  dependent  code  which  must 
be  written.  Another  important  feature  is  the  array  of  tools  available  for  configuring  and  maintaining 
software  source  to  obtain  resulting  operational  code.  These  tools  instrument  source  editing,  library 


creation,  and  multiple  baseline  code  releases.  Other  software  tools  facilitate  documentation  via  cross- 
reference  listings,  flowcharts,  indexing,  and  flagging  code  which  is  not  documented  or  does  not  adhere  to 
the  coding  standards.  If  security-sensitive  models  are  incorporated  in  the  system  (i.e.,  weapon  system 
performance  data),  other  features  which  can  not  be  overlooked  are  user  and  group  file  access  and  update 
protection  via  authorized  accounting  and  password  system  procedures  including  external  on-line 
terminals. 


In  ongoing  developments,  there  is  an  increased  trend  to  micro-code  frequently  used  software 
functions,  such  as  linear  function  interpolation  (LFI).  These  selected  so-called  “firmware”  features  are 
then  considered  to  be  “hardwired”  in  a  read  only  memory  (ROM).  There  is  some  professional 
disagreement  as  to  just  how  firmware  should  be  designed,  documented,  and  maintained.  The  proliferation 
of  erasable  and  programmable  ROMs  and  writable  control  stores  (WCS)  devices  is  a  testament  to  the  fact 
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that  firmware  designs  do  not  remain  static  once  defined  and  implemented.  Their  use  does  permit  efficient 
solutions  to  time-critical  function  execution.  However,  it  is  important  to  have  detailed  design 
documentation  concerning  the  flexibility  and/or  limitations  incorporated  from  an  application 
programmer's  viewpoint.  If  vendor-supplied  ROMs  are  incorporated  and  changes  are  anticipated,  the 
nature  of  the  changes  and  the  party  responsible  for  making  and  maintaining  configuration  changes  should 
be  clearly  delineated. 

Another  software  support  design  issue  concerns  the  best  way  to  incorporate  and/or  simulate  on-board 
processing  device  functions  and  subsequently  how  to  introduce  and  maintain  upgrades  associated  with 
these  devices.  The  discrete  training  modes  of  freeze,  playback,  advance,  plus  evaluation  scoring  logic  are 
not  directly  compatible  with  real-time  processing  devices;  thus  real-time  flight  operational  programs 
cannot  be  interfaced  without  some  modifications  to  the  operational  flight  code.  These  codes  are  typically 
implemented  as  firmware,  and,  as  such,  inherit  the  aforementioned  change  procedure  problems.  Add  to 
this  the  fact  that  on-board  processing  devices  are,  in  general,  comprised  of  highly  specialized,  custom- 
tailored,  ruggedized  hardware  components  which  are  more  expensive  and  limited  in  quantity  when 
compared  with  off-the-shelf  commercial  equipment.  Reference  6  provides  a  description  of  five  basic 
design  alternatives  for  incorporating  these  functions  into  the  simulator;  namely. 

“I) Actual  (or  equivalent  non -flight-qualified)  onboard 
computer  (OBC)  hardware 

2)  Translator/compilers 

3)  Interpreters 

4)  Functional  simulation 

5)  Emulation 

Except  for  the  functional  simulation  approach,  all  of  these 
techniques  utilize  operational  flight  software.  Use  of  actual 
on-board  computer  flight  .-oftware  i>  often  necessary  to 
meet  simulation  fidelity  requirements  and  avoid  time 
delays  inherent  in  fumlicnal  simulation  software 
development  and  to  t/ verification  processes.  Software 
changes  to  on-board  programs  occur  with  very  short 
notice.  Therefore,  the  simulator  software  should  be 
rapabie  of  being  rapidly  updated  and  reverified,  and  any 
equipment  or  software  required  to  expedite  this  operation 
must  also  be  provided.* 

In  summation,  a  complete  multiple-processor  configuration  design  should  include  the  delineation  of 
any  and  all  processor -related  options  which  will  be  utilized  to  develop,  implement,  operate,  maintain,  and 
up-grade  the  operational  trainer  computational  subsystem.  Any  and  all  anticipated  enhancements  should 
be  clearly  specified  as  to  the  type  of  changes,  responsible  party,  change  procedures,  and  configuration/ 
quality  assurance  procedures. 

This  section  has  emphasized  the  flight  training  simulator  characteristics  and  multiple  processor 
configuration  selection  consideration.  The  following  sections  address  the  computational  configuration 
design  evaluation  with  respect  to  multiple-processor  performance  features. 


3.  GENERIC  MULTIPLE  PROCESSOR  MODEL 

3.1  Multiple  Processor  Performance  Terminology 

TBE  has  enumerated  various  performance  evaluation  features  which  are  applicable  to  multiple 
processor  application  design  configurations.  In  order  to  define  these  features.  Figure  5  is  used  to  present  a 
simplified  schematic  of  the  active  components  during  a  real-time  flight  training  simulator  operation.  Note 


the  computational  subsystem  interfaces  with  Nt)  training  device  stations  and  NI  instructor  stations.  The 
computational  subsystem  employs  a  real-time  program  comprised  of  NT  operating  system  and  application 
tasks  implemented  to  provide  automatic  computations,  logic,  and  I/O  for  a  specified  set  of  training  mix 
activities.  The  task  reference/update  NB  distinct  data  blocks  to  collect/provide  the  real-time  inputs  from 
responses  to  the  trainees  and  instructors. 


Figure  5.  Generic  multiple  processor  configuration  components 
for  flight  training  simulation. 


The  computational  configuration  hardware  is  basically  a  set  of  NP  processors,  NM  memories,  and  NL 
communication  links.  The  external  peripheral  devices  may  be  categorized  as  general-purpose  equipment 
versus  special-purpose  peripherals.  Generals-purpose  includes  card  readers,  printers,  magnetic  tape 
drives,  disc  units,  development/maintcnance  stations  and  other  standard  computer  peripherals.  Special- 
purpose  refers  to  the  training  station  and  instructor  stations  devices  to  include  controls,  instruments, 
displays,  visual  imagery,  motion,  and  “ g ”  force  equipment  requiring  computational  subsystem 
monitoring,  control,  or  sup  nor*  It  should  be  noted  that  the  special-purpose  devices  may  in  fact  be 
standard  general-purpose  devices  such  as  a  graphics  CRT,  but  they  represent  a  training  application- 
peculiar  interface.  In  some  cases,  a  given  device  may  be  interchangeable  in  providing  both  training 
functions  and  general  system  opera tion/maintenance/development  functions.  This  flexibility  is  one 
example  of  the  built-in  complexities  which  makes  the  separation  of  special  application  features  from 
standard  general  vendor-supplied  computation  support  features. 


The  generic  types  of  computational  interfaces  with  given  types  of  peripherals  assist  in  defining  the 
following  multiple  processor  performance  terms: 

1.  Application  load  timeline 

2.  System  throughput 

3.  Individual  processor  utilization 

4.  Individual  memory/storage  retrieval 

5.  Communication  link  traffic. 

In  addition.  Figure  6  provides  two  extreme  design  alternatives  with  respect  to  multiple  processor 
configurations  which  can  influence  the  methods  for  representing  and  accounting  for  system  benefits  and 
penalties  incurred  as  a  result  of  specific  application  design.  Flight  simulators  in  general  tend  to  combine 
these  techniques  as  donoted  in  Figure  7.  Another  important  feature  to  note  is  that  a  given  trainee  device 
station  (I)!  or  [)2  in  Figure  7)  is  generally  comprised  of  several  different  peripheral  devices  which  may  be 
serviced  by  different  computational  subsystems  (for  example,  the  visual,  motion,  and  instrumentation 
subsystems).  These  features  further  complicate  the  traceability  of  a  given  trainee  input  to  its  incorporation 
as  part  of  the  simulated  response.  Each  of  the  aforementioned  performance-related  terms  is  defined  in  the 
following  subsections. 

3.1.1  Application  Load  Timeline.  In  order  to  evaluate  performance  of  any  system,  one  must  specify 
the  application  load  timeline  to  be  used  as  a  performance  measurement  baseline.  The  fidelity  of  the 
baseline  application  load  has  a  direct  influence  on  the  type  of  performance  measurements  which  can  be 
determined.  For  example,  at  a  preliminary  design  level,  a  designer  may  wish  to  look  at  shared  resource 
requirements,  as  a  function  of  time-varied  training  mixes,  to  obtain  a  preliminary  estimate  of  processing 
extremes  and  configuration  tradeoffs  at  a  functional  level.  \t  the  system  validation  test  point,  actual  test 
pilots,  instructors,  weapon  operators  or  other  appropriate  -experts”  may  supply  a  planned  real-time 
interactive  baseline  load  for  system  performance  evaluation.  Rcgardlf".  of  the  level  of  performance 
evaluation,  it  is  important  that  a  baseline  set  of  load  specification  parameters  and  conditions,  plus  the 
performance  measurements  sought,  be  defined  prior  to  delineating  detailed  means  for  the  performance 
evaluation.  This  subsection  delineates  load  parameters  which  characterize  the  flight  training  simulator 
computational  load  at  various  points  during  the  system  life  cycle. 

To  prop'-rly  represent  a  baseline  load,  one  is  interested  in  identification  of  the  simultaneous  training 
activities  which  are  required  to  be  serviced  by  the  computational  subsystem  at  any  one  time.  The  baseline 
source  for  this  loading  information  is  best  maintained  as  part  of  the  training  facility  specification.  As  a 
minimum,  critical  loading  factors  include: 

1.  The  types  of  aircraft  to  be  modelled 

2.  On-board  crew  stations  to  be  modelled,  including  controls,  instrumentation,  visual,  motion, 
and  “g”  equipments 

3.  Training  mix  of  standalone  positional  training  versus  coordinated  multiple  crew 
configurations  to  be  supported  in  terms  of  general  facility  training  scenarios  and  maximum 
number  of  aircraft/positions  involved. 

4.  Automated  training  guides  to  be  keyed  in  order  to  control,  perform,  monitor,  and  score 
training  scenarios  defined  in  c. 

From  these  required  capabilities,  the  computational  system  engineers  establish  a  timing  and  sizing 
budget  whi<  h  is  based  upon  and  traceable  to  a  set  of  mathematically /logically  expressed  computational 
subsystem  requirements.  As  a  minimum,  the  functional  tasks  should  be  characterized  in  terms  of 
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Figure  6.  Extreme  configuration  alternatives  for  processor/memory/ 
peripheral  device  communications. 


FACILITY  LEVEL 


Figure  7.  Large  flight  training  computational  facility  configurations 
incorporate  combinations  of  dedicated  and  shared  communication  design. 


parameters  listed  in  Table  2.  Timing  should  be  stated  in  terms  of  functional  I/O  rates,  module  iteration 
rates,  and  critical  control  path  sequence  (unconditional  and  conditional)  coordination  constraints  of  the 
mathematical  model  tasks.  Sizing  should  address  the  I/O  interface  parameters  and  volume,  temporary 
computational  state  data,  and  prerecorded  data  base  structure  and  parameters  necessary  to  support 
mathematical  model  computations.  To  further  clarify  the  I/O  interfaces,  the  application  data  blocks 
should  be  defined  in  terms  of  characteristics  listed  in  Table  3. 

During  the  design,  the  requirements  timing  and  sizing  budget  provides  one  of  the  few  measuring 
sticks  as  details  are  analyzed  and  allocated  with  respect  to  alternative  candidate  configurations.  Because 
each  simulator  development  organization  has  its  own  method  for  estimating  the  current  design  timing  and 
sizing,  it  is  very  difficult  to  compare  two  competing  designs.  In  most  cases,  the  success  or  failure  of  a 
design  does  not  become  known  unitl  it  has  been  coded  and  implemented  on  the  hardware  (which  is 
generally  a  year  to  two  years  after  the  requirements  are  baselined  and  the  development  effort  initiated). 
At  this  point,  it  is  hard  to  determine  if  a  failure  is  due  to  inadequater  hardware,  software,  or  if  the  timing 
requirement(s)  are  inappropriate.  In  other  words,  the  system  failure  to  provide  a  given  training  capability 
may  be  traceable  to  design  and/or  requirement  problem  areas.  Tools  are  needed  which  can  help  identify 
design  versus  requirement-related  bottlenecks  and/or  inconsistencies.  Tools  which  can  measure  or  verify 
current  design  parameters  with  respect  to  given  requirements  measures  would  fulfill  part  of  this  need. 
This  requires  that  certain  aspects  of  hardware/software  design  be  standardized  to  trace  application  load 
requirements  to  the  design  components  which  are  to  handle  the  load.  To  better  understand  the  application 
load,  the  other  performance  measures  identified  in  3.1  must  first  be  considered  in  terms  of  the  load 
environment. 
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Table  2.  Task  Load  Characterization 


Attribute 

Values 

l  nit/Meaning 

Identifier 

(^Character  Mnemonic 

Provides  a  unique  identifier  for  cross- 
reference  and  labeling  purposes 

Source  Language 

KM  Character  ('ode 

Must  match  entry  in  the  master  source 
language  list  maintained  for  current 
processor  technology 

Instruction  Mix  for  Each  instruction  Type: 


•  Instruction  Identifier 

10-Character  Code 

Must  match  entry  in  master  simulator 

•  Sizing  Count 

Positive  Integer 

instruction  mix  identifiers 

Number  of  times  this  instruction  appears 

•  Execution  ('.ount 

in  code 

Number  of  instruction  interactions 

Average 

Positive  Integer 

considering  looping  conditions  for 
average  and  worst-ease  logic 

Worst  Ease 

Positive  Integer 

Data  Retrieval  for  Each  Task  Input 

•  Block  Identifier 

ft  Charcters 

See  Table  3 

•  When 

6-Characters  Code 

=  'START' 

All  records  read  at  first  of  task  before 

=  'ALONG' 

main  processing 

Records  processed  one  at  a  time 

•  Average  Input 

Positive  Integer 

Records 

•  Minimum  Input 

Non-Negative  Integer 

Records 

•  Maximum  Input 

Positive  Integer 

Records 

Data  Storage  for  Each  Task  Output: 

•  Block  Level 

1  Character 

See  Table  3 

•  Block  Identifier 

6  Characters 

See  Table  3 

•  When 

6-C.haracter  (.ode 

=  ALONG' 

Records  are  output  via  individual 

=  ’END' 

processing 

Records  are  output  just  prior  to  task  exit 

•  Average  Output 

Positive  Integer 

Records 

•  Minimum  Output 

Non-Negative  Integer 

Records 

•  Maximum  Output 

Positive  Integer 

Records 

Enablement 

•  Type 

4-Characler  Code 

=  'TIME' 

Time  Enabled 

=  'DATA' 

Data  Enabled 

=  'SLVD' 

Slaved  to  Master  Task 

=  'TAD' 

Time  and/or  Data  Enabled 

•  Frequency  1 

Real 

Interations/Second  for  Time  Enablement 

•  Frequency  2 

Real 

Inlerations/Second  for  Data  Enablement 

•  Frequency  3 

Real 

Interations/Second  for  Slaved 

Table  .1  Data  Load  Characterization 


Attribute 

Values 

Init/Meaning 

Identifier 

6-Characler  Mnemonic 

Provides  a  unique  identifier  for  cross- 

Level 

1  Character 

reference  and  labeling  purposes 

=  'S' 

System  Interface 

=  'G' 

Global  (used  bv  more  than  one  task) 

=  'L' 

Local  to  one  task  but  must  be  saved 

=  T 

Temporary  scratch  area  for  a  gven  task 

Discipline 

4-Character  Code 

Provides  basic  I/O  requirement  for 

=  'FIFO' 

determining  suitable  memory  device 
allocation 

Queue 

=  'LIFO' 

Stack 

=  'SEQ' 

Sequential 

=  'RAN' 

Random 

=  'ROR' 

Ready-Only  Random 

=  ROS' 

Ready-Only  Sequential 

=  'CBl'F' 

Circular  Buffer 

Sizing 

•  Maximum  Records 

Positive  Integer 

Records 

•  Bits/Character 

Positive  Integer 

Bits 

•  Characters/Word 

Positive  Integer 

Bytes 

•  Average  Words/Record 

Positive  Integer 

Words 

•  Maximum  Words/Record 

Positive  Integer 

Words 

•  Minimum  Words/Record 

Positive  Integer 

Words 

3.1.2  System  Throughput.  When  describing  a  computational  configuration,  one  frequently  relates 
to  the  throughput  capacity  of  the  system.  Data  throughput  is  measured  in  terms  of  bits  or  bytes  per  second 
being  transferred  into  or  from  the  system.  Processing  throughput  is  measured  in  instructions  per  serond 
(IPS)  with  typical  reference  being  in  terms  of  thousand  (KIPS)  or  millions  (MIPS)  of  instructions  per 
second.  In  the  case  of  a  multiple  processor  configuration,  the  maximum  throughput  assumes  all  processors 
are  busy  and  that  the  maximum  I/O  configuration  capacity  is  active. 

« 

In  designing  a  system,  one  rarely  achieves  or  even  desires  maximum  throughput.  For  one,  a  system 
operating  at  maximum  capacity  leaves  no  spare  processing  or  I/O  capabilities  for  potentially  heavier  loads. 
For  another,  it  is  a  well-known  observation  from  queing  theory  that  a  system  which  exceeds  much  more 
than  80%  capacity  is  very  susceptible  to  excess  operating  system  overhead  thrashing  or  shared  resource 
bottlenecks.  Thus,  a  design  for  a  given  application  should  (as  observed  in  Section  2.3.4)  incorporate 
sufficient  spare  capacity  and  growth. 

As  denoted  in  Section  2.3.4,  spare  capacity  must  be  available  at  each  of  the  basic  configuration 
component  levels  (i.e.  processor  unit,  memory  module,  or  I/O  communication  link).  Growth  is  the  ability 
to  add  more  components  to  the  configuration.  It  should  be  noted  that  growth  features  provide  more  raw 
capacity  but  do  not  necessarily  increase  application  throughout  unless  some  design  and/or  match  model 
changes  are  also  made.  This  is  particularly  true  for  the  rase  where  a  given  sequence  of  dependent  tasks  are 
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the  limiting  (actor  tn  meeting  a  specific  I/O  port-to-porl  timing  response.  In  this  situation  the  task 
sequence  represents  a  thread  of  activities  which  is  sequential))'  activated  by  a  given  input  port  at,  say,  time 
t  and  is  to  compute  a  response  needed  for  a  given  output  port  at  time  t  +  At.  By  definition,  the  thread 
activity  is  a  sequential  process,  which  negates  simultaneous  use  of  parallel  multiple  processors  in 
configurations  comprised  of  homogeneous  processing  elements.  However,  certain  parts  of  the  sequence 
may  be  best  characterized  by  selected  special-purpose  functions  which,  if  properly  matched,  may  execute 
more  efficiently  by  incorporating  either  special-purpose  processors  and/or  firmware  extensions  to 
augment  a  general-purpose  processor.  Care  should  be  taken  to  keep  the  design  solution  simple  and  to 
maintain  a  minimum  number  of  well-defined  yet  flexible  special-purpose  interfaces. 

The  real-time  task  path  data  dependencies  tend  to  be  more  complex  than  a  set  of  parallel  unrelated 
threads.  Figure  8  represents  a  simplified  set  of  the  task/data  relationships  extracted  from  preliminary 
design  (March  1979)  of  the  visual  general-purpose  computational  subsystem  of  the  Advanced  Simulator 
for  Pilot  Training  (ASPT).  Figure  8  illustrates  the  interfaces  with  the  special-purpose  visual  computer 
image  generation  equipment  (AOBJL.  MODPLTST,  DYNDATA.  PAOL.  DIRUTE.  CAIPT,  AOLT), 
aircraft  math  model  position  updates  (RAWPAS  and/or  SIMPOS)  and  visual  control  panel  consoles  for  two 
cockpits  referenced  as  “A”  and  ”B.”  The  taks  of  Figure  8  represent  the  process  relationships  to  be 
handled  via  CPI' A  and  CPLB  activated  via  a  real-time  30-hertz  interrupt  pulse.  In  this  particular 
example,  the  detailed  output  (AOBJL.  MODPLIST.  and  DYNDATA)  from  the  previous  iteration  is  being 
output  to  the  special-purpose  display  generator  while  the  new  position  information  is  being  used  to 
determine  outputs  for  the  next  iteration.  The  mathematics  incorporated  to  integrate  the  position  inputs 
typically  require  several  iterations.  Thus,  an  input  at  time  t  influences  the  output  through  time  t  +  nAt. 
where  n  represents  the  number  of  frames  which  constitute  the  number  of  positional  inputs  used  to 
compute  any  part  of  the  visual  display.  In  this  instance,  the  port-to-port  time  can  be  reinterpreted  as  the 
time  required  to  completely  execute  n  real-time  frames.  Each  frame  must  be  executed  in  less  than  a 
specified  At  seconds  (0.033  second  in  example)  to  meet  the  math  model  requirements. 
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Figure  8.  Real-time  application  task  flow. 
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Ill  the  evolution  of  real-time  flight  simulator  designs,  the  basie  mathematical  models  have  been 
modularized  into  parallel  tasks  requiring  specified  iteration  rates.  These  tasks  are  generally  characterized 
by  a  real-time  application  cycle  (generally  a  one-second  interval)  which  is  subdivided  into  frames 
characterized  by  iteration  rates  such  as  1/second.  4/second.  10/second  and  20/second  frames.  The 
allocation  of  these  tasks  to  a  multiple  processor  configuration  is  an  optimization  problem  which  has  been 
addressed  in  the  Software  Partitioning  Study  (Reference  7).  For  purposes  of  this  study,  it  is  sufficient  to 
state  that  for  a  given  real-time  task  partition  allocation  of  the  math  model  to  a  multiple  processor 
configuration,  certain  assessments  can  be  made  regarding  application  throughput  and/or  bottlenecks.  The 
supporting  design  data  and  techniques  necessary  to  predict  system  application  throughput  are  defined  in 
Section  4  as  part  of  the  generic  multiple  processor  performance  prediction  simulator. 

In  general,  the  maximum  system  throughput  analysis  requires  detailed  analysis  of  the  specific 
application  math  model  and  its  design  alternatives.  In  most  cases,  time  permits  only  a  few  alternatives  to 
be  considered.  As  long  as  the  design  timing  and  sizing  measurement  estimates  are  in  tolerance,  the 
designer  tends  to  expand  a  given  alternative  being  pursued.  If  a  bottleneck  is  found  or  suspected,  it  is 
generally  characterized  as  either  being  compute  bound,  memory  bound,  or  an  I/O  bound  problem.  This 
leads  to  the  necessity  of  individual  component  analysis  throughout  the  design  effort.  If  additional  or 
replacement  processing  components  cannot  solve  the  bottleneck,  then  either  a  further  segmentation  of  the 
math  model  or  a  compromise  in  iteration  rates  is  required. 

3.1.3  Individual  Processor  l  tilization.  A  processor  unit  performs  or  executes  based  upon  a  stored 
program  (whether  it  be  a  micro,  mini,  or  mainframe  based).  The  stored  program  for  early  I960  flight 
training  simulators  was  totally  customed  to  meet  the  challenging  real-time  processing  constraints  of  flight 
simulation.  Generally  a  super  general-purpose  digital  mainframe  performed  the  mathematical  model  logic 
serving  D/A  and  A/D  customized  interfaces  with  the  cockpit  training  station  instrumentation.  As 
additional  subsystems  of  motion,  force,  and  visual  aids  were  added,  multiple  processor,  general-purpose 
combined  with  special-purpose  equipment  required  further  refinement  of  mathematical  representation 
and  computational  requirements.  These  enhancements  quickly  saturated  the  processors  for  which  the 
original  flight  simulations  had  been  employed. 

Meanwhile,  hardware  technology  proliferated  in  areas  of  real-time  control,  command,  and 
communication  necessary  to  support  various  distributed  processing  configurations.  In  addition,  software 
design  technologies  of  top-down  modular  structure  format  provided  many  new  design  alternatives  for 
processor  utilization.  This  design  freedom  has  proliferated  instruction  set  architecture,  as  well  as  software 
development  languages  and  support  tools.  One  major  fallout  of  this  was  the  fact  that  independent  detail 
design  of  the  application  can  influence  the  structure  of  the  real-time  operating  system  necessary  for 
managing  processor  resource  utilization  schemes.  In  particular,  the  processor  rules  for  generalized 
multitasking  (as  opposed  to  customed  application  executives)  have  been  expanded  in  the  vendor- 
supplied.  real-time  operating  system  features.  These  schemes  vary  slightly  from  one  processor  to  another, 
but  in  general  address  real-time  critical  task  scheduling  problems  of  priorities,  sequences,  data-triggered. 
and  time-triggered  activities.  Many  elaborate  schemes  have  been  devised;  however,  a  few  simple  rules  are 
best  applied  in  the  real-time  flight  simulation  environment  due  to  its  cyclic  tendencies. 

First  of  all,  there  are  two  major  sets  of  multiple  processor  design  philosophies  for  real-time  processor 
task  assignments: 

I.  Centralized  master  processor  with  slaved  processors  whereby  the  master  processor  controls  the 
task  allocation  and  keeps  track  of  the  real-time  cycle  iteration  counters  assigning  tasks  to 
available  processors.  The  slave  processors  have  a  very  basic  set  of  operating  system  rules 
which  are  driven  by  data  set  by  the  master  processor. 
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2,  Distributed  task  control  operates  based  on  a  predefined  set  of  processor  tasks  and  processor 
task  selection  rules.  This  means  each  processor  has  a  certain  amount  of  executive  process 
control  logic  to  coordinate  and  interface  its  assigned  tasks,  and  data  with  shared  memory  or  1/ 
O  devices  with  explicit  processor  interfaces  to  keep  the  total  process  in  synchronization. 

Regardless  of  the  processor  control  philosophy  selected,  certain  vendor-supplied,  real-time  processor 
tasks  controls  can  help  streamline  eustomed  executives.  These  include: 

1.  Task  prioritv  service  level  assignments 

2.  Task  enablement  criteria 

—  Time  enabled 

—  Data  enabled 

—  Interrupt  enabled 

3.  Task  activation  within  a  priori t \  loop 

‘l.  Task  activation  among  prioritv  loops. 

These  concepts  have  led  to  a  straightforward  table  initialization/table  driven  real-time  task  manager 
which  is  less  dependent  upon  the  specific  application  design,  and  hence  easily  modified  via  changes  to 
control  table  inputs  which  reflect  a  given  design.  The  types  of  tables  and  logic  schemes  to  carry  out  the 
real-time  task  process  controls  differ  among  vendors  and  even  within  vendor  product  lines.  Thus,  an 
independent  modular  computational  application  design,  when  mapped  to  specific  configuration  of 
hardware,  should  account  for  associated  real-time  vendor  support  software  which  is  best  suited  to  the 
design  situation  at  hand.  Automated  techniques  for  matching  design  needs  with  vendor  capabilities 
require  parameter  standards  for  both  design  traits  and  vendor  products. 

Once  a  task  allocation  scheme  is  selected,  the  individual  processor  timeline  may  be  evaluated  via 
static  and  dynamic  analysis  tools.  Static  tools  operate  on  a  given  point-in-time  set  of  constraints,  such  as  a 
projected  worst  case  set  of  constraints.  Statis  analysis  generally  concerns  analysis  of  a  given  single  frame  or 
cycle  interation.  Dynamic  analysis  covers  a  broader  investigation  of  the  design  relationships  and  operating 
rules  to  follow  a  timeline  history  of  interactive  cycles  employing  statistical  and  simulation  techniques 
described  in  Section  3.3.  At  the  processor  level,  the  parameters  of  interest  are  shared  memory  access, 
computational  speed  of  responses,  and  effectiveness/inadequacies  of  processor  throughput  with  respect  to 
iteration  rates,  processor  spare/idle  time,  and  instruction/data  access  and  communication  spare.  Table  4 
summarizes  processor  characteristics  which  influence  performance  evaluation  of  a  given  design. 

3.1.3  Memory  Units.  Memory  units,  for  purposes  of  this  study,  are  used  for  both  application  tasks 
instruction  and  data.  Processor  technology  has  defined  many  levels  of  physical  memory  storage  devices, 
core,  metal  oxide  semiconductor,  magnetic  bubbles,  disc,  and  tape,  to  name  a  few.  The  timing  of  a  task  is 
directly  influenced  by  the  physical  type  of  memory  accesses  it  makes.  Current  processor  addressing 
schemes  have  facilitated  the  ability  to  “map"  physical  memories  to  several  processors  within  a 
configuration  via  multiport  memories.  The  memory  controller  itself  is  typically  a  microprocessor  which 
identifies  the  processor  requesting  I/O  access  and  prepares  to  ship  or  receive  data.  If  multiple  access 
occurs  simultaneously,  the  memory  handler  determines  in  which  order  the  requests  are  to  be  serviced. 

As  with  processor  units,  memory  I/O  performance  features  may  be  determined  by  a  static  point-in- 
time  analysis  or  a  dynamic  representation  of  the  real-time  application  memory  event  time-line.  Table  5 
identified  memory  characteristics  which  influence  performance. 
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Table  4.  Processor  Characterization 


Attribute 


Values 


Unit/Meaning 


3 

i 


Identifier 

10-Character  Mnemonic 

Unique  identifier  for  processor  with  the 
following  attributes 

Operating  System 
•  Multitasking 

A  Levels 

Integer  .CE.l 

A  Number  of  Priority  Levels 

Integer  .GE.O 

These  man\  levels  are 

.LE.  Levels 

serviced  in  a  priority  fashion.  The 
remaining  levels  are  serviced  in  a  circular 
time-shared  fashion. 

•  Enablements 

lnterger 

Enablements/Second 

A  Maximum  Time  Enablement 

Frequency 

A  Resource  Management 

F10.9.GE.0 

Microseconds 

per  Time  Enablement 
AMaximum  Data  Enablement 

Integer 

Enablements/Second 

Frequency 

A  Resource  Management 

F10.9.GF..0 

Microseconds 

per  Data  Enablement 
AMaximum  Slaved  Enablement 

Integer 

Enablements/Second 

Frequency 

A  Resource  Management 

F10.9.GE.0 

Microseconds 

per  Slaved  Enablement 

•  For  Each  Task  Level  L 

AMaximum  Number  of 

Integer  .CE.l 

Task  Level  L 

A  Task  Service  Scheme 

Code 

for  Level  L 

=  'P' 

Priority 

=  *C' 

Circular 

=  'F' 

Firsl-in,  First  Out 

•  Level  Resource  Management 

FI 0.9  .GE.O 

Microseconds 

Simulation  Instruction  Set 
Measurement  for  Each  Benchmark 
Instruction  1 
•  Sizing  Measurements 

A  Number  of  Code  Memories 

Involved 

The  Memory  Type  for  Each 

Code  Memory  m  (the  first 

4-Character  Code 

Must  agree  with  master  memory- 
types  defined  in  Table  5 

memory  is  the  user  task  code  — 
any  other  memories  are  predefined 
for  this  processor) 

A  Length  of  Code  in 

Integer  .GE.I 

Number  of  basic  units  used 

Memory  m 

to  describe  memory  m  (see  Table  5) 

•  Timing  Measurement  for 

k  =  l  Implies  Average 

Each  Code 

k  =  2  Implies  Worst  Case 

Memory  m  and  k  =  l,2 

A  Number  of  Scratch 

Integer  .GE.O 

Data  Store  Waits 

A  Computational  Total  for 

Integer  .GE.O 

Cycles 

All  Memories 

•  Application  Development 

Measurements  Using  Language 

L  of  the  Master  Language  List 
AOne  Item  Development  Charge 

Integer 

Man-hours 

AChange  per  Application 

Integer 

Man-hours 

Instruction  of  this  Type 

».  Memorx  Device  Oiaracteri/ation 


Attribute  Nairn's  l  nil/Meaniiig 

identifier  MM  Jiaraclcr  Mnemonic  Provides  a  unitin'  identification  (or  rat  h 

memorx  device  in  the  technology  data 
base  lor  which  the  following  attributes 
define 


T\  IM* 

l  1 !li;ir;U‘t«*r* 

-  Ko\r 

Read  Onl\  Memorx 

-  ii\\i\r 

Kamiom  Voces**  Main  Mritiorx 

*  KRWt' 

Rotating  Random  Access  Memory 

-  ’SM’ 

Sequential  Mrmorx 

=  VlCS' 

Vi  ritahle  (Control  Storr 

Size  in  Rifs 

•  Minimum 

Positive  Integer 

Kii> 

•  Maximum 

Positive  Integer 

Bits 

•  Increments 

Positive  Integer 

Bits 

Number  of  Different 

Addressable  l  nits 

Positive  Integer 

f  or  Kach  Addressable  [  nit 

•  bevel 

l-<  luirarlrr  ( axle 

=  HIT' 

Hit  Addressable 

-  '(.HIT 

(i-Bit  Byte  Addressable 

-  ’KBIT 

tt-Bit  By  1c  Addressable 

'  VI  <  Hi  1  >' 

Vi  ord  Addressable 

•  Hits/1  nil  bevel 

P.»ili\r  Inl.-j’.T 

Kxrlusixr  of  Parity  or  Krror  Mrlrl 
Korreetion  Hits 

•  Read  \m»  Time 

U.al 

Nanoseconds 

•  Read  ( Arlr  Tint**  1  nit 

Hial 

Nanoseconds 

•  Maximum 

Sequential  l  nils  Transferred 
for  Singh*  Read 

P.oiliw  Inlrprr 

Same  as  1  nil  Lex  el 

•  Vt  rite  Access  Time 

Krai 

Nanoseconds 

•  Vi  ritr  ( lyric  Tiinr/1  nil 

K.al 

Nanoseconds 

•  Maximum 

Sequential  l  nits  for  Single 
Writ**  Am-sfi 

P»>ilivc  ItHcprr 

Same  as  l  nit  Lex  el 

•  Krror  l)rtrrlion/( lorrection 

(»-<  iiara.  l.  r  ( axlr 

-  'PARTI V 

Parilx  Bit 

=  'SKCHKII' 

Single  Bit  Krror  <  Correction 

Double  Bil  Krror  Meleclion 

Number  of  Suppliers  for 

Karh  Supplier  — 

I’osilivr  liilrp.T 

•  Identifier 

III  Uiara.t.r- 

l  nique  Identifier 

•  MTBF 

Krai 

Hours  — Mean  Time  Between  Failure; 

•  MTTH 

Krai 

Hours  — Mean  Time  to  Repair 

•  MS  PM 

Krai 

Hours  — Rescheduled  Prexentive 
Maintenance 

•  MITM 

Krai 

Hours  —  Mean  Time  for  Preventive 

Maintenance 


Mil'll  h  INC- 


.5.1..)  (  innniunn  utimi  l.itll .v  I  In*  Mil  I  i/.il  lull  <•(  -hand 

triplin'.-  -haled  i  om  ill  mi  h  ;H  ion  t.»  I  .nil  Hale  a  \ariet\  1 1 1  r»iil  T 1 1 1  ■  i  * 
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anmn^  multiple  proee — or- 
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I.  \\  hill  i-  I  In*  maximum  nmiiher  <»|  |ii<m  *r— oi  .mil  meiimrie-  xxhieli  r.i,i  <1 1  <■<  1 1  \  <-|  \  utilize  a 
-hared  communication-  Inn*.' 

II.  How  mill'll  huill-iu  rommniin  ai  mu  redumlam  \  m*ee--arx  from  an  opera!  mnallx  reliable 
\  irw  | >« >i 1 1 1 

>.  \\  ha  I  alternative-  r\i-l  lor  ninth!  \  in"  ami  ipucklx  permit  reeoni  i^miiii^  o|  a  -x-trm  to  hv- 

|  >;i  —  a  detective  roll!  ipi  rat  mil  <  otiijiomit!  ' 

l  ilt*  aiiwvrr-  lo  1  lir-<'  <| nr-l  ion-.  din-*tl\  i:illimi<<-  tin*  -elerimn  n!  ilnl n  alnl.  -hared.  and  backup 
communication  dr\  nr-  incorporated  min  I  li^ht  training  >i  inula  tor  <  onl  i^nrai  ion  de-ipi-.  One  ol  I  In*  major 
|»rrf  orttianrr  <-\ aluahoii  arra-  of  loinrni  i-  "\\  fiat  |  ><  il«  *  filial  framing  niodr-  will  tin*  candidate  dr-i^n 
-upport  in  degraded  mod*  -  ha  .,  lo--  of  a  proee--oi  'im-nmrv /penpheral/romliiie  whirl)  re(piire> 
trouble-hoot  inn  maiiiliii.ini  <•  and 'oi  i< pair)'  I  In-  randidalr  <  on  I  i^urjl  ion-  analvzed  trnd  to  have 
prej— ikium!  (iro<  < -—or nn  rm»rv  afl<»«  af;«»u-  whu  fi  become  hardcoded  m  ihrir  rralizatmn.  Thi-  make-  it 
vrrv  difliriill  hi  rr<  onf inm ••  tin-  -oltwan  a-  w<-ll  a-  phv-i<al  hardware  l  ommiinn  ation.  mile--  it  wa-  an 
original  dr-inn  i  <nitinnn  \  mpon  nn-ni  to  I »**  ahlr  to  imniiipirr  under  rrrlain  romlil ion-. 

\-  rrlrrnn  rd  in  I  ifiniv-  t»  ami  ..  a  wide  varietx  ol  candidate  dr-ij'u  altrrual iv <•-  ranpe  from 
dedicated  _'-wj\  to  multiple  ii-wjx  <  onintnnn  atmn  <  <»nhntiratmii-.  Tin*  llinlil  training  roiii[iutational 
-uh-\ -trin  mu-l  In*  aide  lo  cxternallv  -erv  n  r  a-\  m  hronnu-  and  m  linmou-  dr\  ii  e-  ol  varied  -peed-  and 
huller  Iriinth-.  I.itrrnallv .  hi«:h--pe«  <1  parallel  data  iran-ler  dev  n  r-  are  <  iirrmlh  rmploxrd  t<i  -hip  lmr-1 
I ran-mi— ion-  ol  parameter-  Irom  one  computational  -uh-v-tem  in  another  l  «»r  example.  tin*  -hippinn  o! 
aircraft  math  model  pn-ilion  data  to  vi-ual  im.in<  ^<-m  ratnm  lomputatmn-  i-  done  ii-injj  a  hijj;h--prrd 
data.  IIs!  K  pro<  »•— or-io-pr oi  »•— or  han-in  m  \M'I  Within  a  n,\en  computational  -nh-v -tern.  a 
in  ill  tipi  <><-<*- -or  I  mi-  i-  common  I  \  » i -•  d  to  •  om  in  min  ale  with  -hared  menmrv  ami  to  pn*v  id«*  pr<  ier--or-  to¬ 
pi  ore— or  rommiinif  at  ion. 

I  he  communication  area  ha-  hern  nh-ntil  i«*<l  a-  a  major  ana  lor  further  -tud\.  I  or  purpo-c  of  thi- 
-tudv.  tin*  roiuiiinnii  ation  model-  lot  a  eandidah  eonlijimatmn  are  drlinrd  mi  term-  oi  inlerhn  inj: 
pro«  r— or-,  meiiiorie-.  and/or  peripheral-  with  a  ma\imum  I  ()  rate  winch  cannot  he  e\ceeife<l.  fool-  tor 
communication  rehaiulilx  ami  rec  fill  i^iir.iinm  analv-i-  will  rnpine  adfiitmnal  -lud\  to  idrntilv 
appropriate  parameter-  am!  proim-me  m*w  technologic-  I  Ini-,  the  p>al-  ami  re<  om mended  tool.-  ol  thi- 
-indx  a--uim*  lulls  opt  rational  eommiiiii*  ation  f onl ipiratmn  wliieli  an-  defined  a-  part  of  tin*  candidate 
dc-i^ii  configuration  licin^  <*x  ahiat<*il. 


:\.2  («mIs 

1  he  j»oal-  -elected  lor  tin*  multiple  pmrc--or  performance  model  were  oriented  toward  liming, 
utilization,  ami  initial  re-ourre  prediction-  (ia-ed  upon  jiivrii  eamhdatf*  configuration  d<*-i^n  -predication 
(wliieh  include-  -oftwarr  allocation-!  umler  an  anticipated  training  enx  ironment  load  which  incorporate- 
teallire-  ex.pre— Cfl  ill  .5.1.  I’lie  pial-  c-tahli-heil  are  a-  lollow-: 

I.  IVeiliet  proee— <»r  lllill/atmtl  -lali-tie-  with  re-peel  hi  the  real-time  exele  to  im  Imle: 

•  M'l'1  n  ation  ta-k  liming  hi  int  lude  eompntatmn.il.  I/U  wail,  and  -impended  wail  time 
-lali-tif  - 

•  Itc-otirrr  inariaLM‘tm*nl  o*  erliead  timini: 


IVediel  irallu  ipu-m*;  -tali-tu  •-  w 1 1 1 1  r* •  - j »» •«  l  I*.  nal-nim  *  vt  li  'n  un  hide 

hu-  v .  i«l It- .  .uni  wail  time-  f * •  r : 

•  I  hannel  tjiiti/atim< 

•  Itllerpl'ot  *  --ol  If  *lti  —  f  t'l  - 

•  MriilulX  /  pro*  : » ;i  i  *  - 1  *  *  i  - 

•  (vele  ami  thread  pui  i-lo-por*  limine  -lah-tu- 

I  nun  the  'l.ili'lH'.il  iu  f !  n  i  urn  -  ■ h  mt  mum  t  hr  lol  m\\  m*:  ml  it  a!  de -i»»n  tv  »tmi  r>  -  w  h  h  i  r  •  |m*»  ' 
to  un-ati-lied  limine  and 'm  -pan  eiowih  i <ipiinumm- : 

•  t  .ritu  al  path  la-kMala  | ». i« •  i n  • 

•  I’olt-lilia!  hoolleiie*  k- 

1  IVov  nil  -ummaru-  ol  -e|**.  md  iamlida*  o*ul  i«ji.ra,  un  utilization,  *pi  ••.hj*.  ..ml  Miheal 
re-oiirre  -lali-lu-  I « whnl:  «mal-  I.  Lh  ami  \  It.* v «  Im*-ii  den-nu h md.  ^rHion  I  ..  pn*\u|e- 
lormal-  ior  Min  ilit*  report  -ummane-  n.  I  ijiurr*  IJ  ’iimjeh  I 

>.  I'or  -fleeted  altrrnat i\  r  *  a  ml  id  a  I »•  <  on  1 1 jj 1 1  ra i ihiiv  pi  o\  nh  -ide-h\--id«  -u  m inarm-  oi  -e  lee  led 
-lali-lm-  Irom  m,a|-  I.  2.  ami  1. 

In  e-lahli-lnne  fhe-e  de-i^n  t*,»ai-  I  HI  <  .  m-i  dm  *d  a  w  ide  v  a  riels  «>f  p*rlm -mam  e  fma-urefueu  f  </oal- 
Till*  ha-ie  a--mni»lion-  ami  lea-ihh  -ample  prnhiem  i  lianmtei  i-i  n  -  air  now  pr ■«  -•  a  1 1  •  j  n>  hum.1,'  I  iirt  I  mi 
ill-iellt  to  tlir  -eleelioll  ol  till-  -pei  ill.  -*•!  oi  yo.il-. 

d.J.I  lltl'h  (null  >rlnfi<tn  Jw/m/Mfo//'*  lot.il-v-iem  perlor  mam  -  ■  r\ .dilation  i*  an  r\ oin 1  m'l.ii  s  . 
iterative  prne«*,ji;’t  wlheh  iMMsiii-  u  ill)  roin  ephialK  r«**l  li. mi  ini’  » apahdilm  ami  eim  <  i  j  -m  •  ■•-Inti 
With  ail  jrrrptahm  oprr.ll  iollal  tiaimiie  dev irr.  I  lir  eoinpntulioiiui  ({c-i^ii  pro'  nlr-  ill  M),eii  iavoin  i  >1 
hot  h  hanlwair  ami  -ol  I  wan-  eomputm  m-  in  lr  rin-  ol  I  hnr  in  I  •  -  r  r a*  la  I  ion -hi  p-  am  irtailm  j.ime*-  ;  a-k  I  iow 
I  parallel  and  -enal  ’ .  data  depende  mm-.  and  a  I  lot  a  I  ion  *  .1  re-oiin**-  t « »  *rr\  i  t  •*  the  nap  j  :  - '  om  pu  lai  tonal 
-\-tem  It1  ,  i- I  ji  !  hr  In-!  a--umptuu  i-  'la!  a  ha-*  line  »  mu*. maiumal  -uh-  •*  ■«»  i  *  « j :  1 1  ?  *  niriil* 
model  pn>\  nii  -  a  m.|t  hr m.n  u  a i  and  t  *;»u  a t  •’ )  a n  -  tat  n»  •  *1  i n p  ’  ::«i  a--o«  jaird  eom |  •  •Ha  ■ ,  **  .  j. ;  os  id* 

mil  pill-  alone  wi'l.  a-ou  i.ited  n‘-pon-<  i<»  he  pi*-,  **.  wimn  -.-lem  heroine-  op«  a  mi.  -•  *mid 

a->uniplion  i-  that  the  de-i^n  peilmihaiu*  rail  lie  nira-tn  *«i  with  ;.-pn  I  I*,  lit-  -«  napnie.  ,<•  eiven  an 
appropriate  -«  t  <d  mi  a-unne  tool-  n?i!i/»ne  1 1 ' * •  -♦*!•••  t-  d  fj**>ien  *»ir;d-  pr*--*  oi.  d  in  tin-  -<  <tinn 

I  he-e  a--nii.pl  ion-  peiinit  j*i  f  l*n  .,!.,m  e  e\ainai«>n  .net  prr<h«  non  with  rr-peet  to  ijuantdi'hl* 
i  **♦  p  1 1  re  me  m  I  1 1 ,  *  $  1 1  li.iaiiMM  -liimlatm  pm  lorniam  **  al-*>  m*orpmate-  human  lartm-  wl;n-h  *lral  with 
-llhjrrtivr  nira  lire-  ol  pen  ep|  ion-  eniolioti-.  aid  -rn-alioli-  I  nr-e  l\pe-  ol  perl  *  >l  ni.i  lire  mra-ut'e- 
leipiire  .i  proto!  v  pe  operaiiou  il  dr\in  with  *  •*  m  I  n»l  I  - -i  1  -l.li-heal  e\p«  riimml-  ol  a*  Inal  am  rail  and 
-mmlaled  ain  rall  oprratu*n-.  .Vvrul  » -\irn-ivr  lo\  1 1  laediln  -  r\i>i  (in  the  \ir  l  our  ami  the  National 
\eron. mtu  -  ami  sparr  \dinini-l  rat  ion )  whnh  pro\  ide  power!  nl  roinpulahonal.  vi-nal.  inoln-n.  cjm  me. 
ain  rall  model-,  ami  rn  w  -tation  nioih-l  tool-  lor  Ir-tine  ami  evaluating  iu*w  .deonlhm-  lor  a--e--*ne 
human  I  a*  tor-  a--oi  uited  with  dr-i^n  oi  trainine  -imnlator-  and/or  oprral  ioiiai  ainrall  env  irmiinni!-. 
I  Inn.  a  third  a--iiinpliou  in  -rlr*  tiuji  the  mnlh[de  proee--or  dr-ien  e\  iluali*m  e(,al-  i-  that  tin-  human 
l.ietor-  have  hern  -tudied  and  were  meorporan*d  a-  part  ol  tin1  ipiantil  iahle  <  <»mpu!al mnal  ieipnr<Mm  nt- 
or  thal  aelliai  proletvpe  development  will  he  rnpiired  to  addle--  the-e  i--ue-. 

I  he-e  a--iimptioM-  permitted  ll»e  tool-  and  teehnnpie-  de-ij»m*d  1>\  thi-  -tmlv  lo  addle--  -perdu  allv 
the  miilliple  proi  e— or  eonl'jiuralion  i|e-ien  leature-  in  term-  ol  applu  aiion  tuning,  -i/me.  thrmi^hput- 
aml  therein  tin*  mean-  lor  identifvine  anv  potminal  ile-i^n  !>o( t lem-rh-.  ami  provide  lor  evaluating 
alternative  eamliilate  ile-i^n-  prior  to  protolvpi-  development  and  le-tm^.  Ihe-e  tool-  rail  al-o  provide  a 
mean-  lor  evaluation  «»|  propo-ed  modil  i*  at  ion-  or  addition-  to  e\i-tine  operational  th^iht  ttaimn^ 
-i m illation  eoinputalionai  eoni i^u ration- 


H.2.2  Saiiiftiv  i’ruhtcm  ('.imractwistirs.  Ilu*  b;i*ir  tool'  anil  Icrhunpic*  «.«*h*<trd  to  *uli*l\  tin*  goal- 
mii>t  hr  responsive  to  problem  area*  of  ruudidatr  flight  training  simulator  dc*ign  configuration 
evaluation.  For  thi*  purpo-e.  TliK  had  defined  sample  problem  feature*  whirl)  were  to  he  incorporated 
into  the  feasibility  disrn>sion  of  automated  design  evaluation  tool  of  Section  I.  \  manual  demonstration 
necessitate-  a  simplified  model  of  a  real-time  multiple  processor  configuration  design. 

The  sample  proldem  is  described  in  term-  ol  a  generic  multiple  processor  configuration  depu  ted  in 
Figure  1  hi*  configuration  support*  two  training  dev  ire  station*  (1  >,  and  I  M  via  external  eomputational 
*uhs\slem  interfare*  Kj.  K2*  F:t.  I\4.  K r>.  I\,;.  f\7.  and  FH.  Processor-  P,.  P2.  and  P ,  represent  a  general- 
purpose  mini-computer  multiprocessor  svstem  with  a  -hared  data  bus  lj.  and  shared  memorv  M 2  and 
private  memories  \|,  and  \l;l  lor  IV,  and  P7.  respectively .  \  high-speed  data  link  \  ,  interface*  the  master 
processor  Pj  with  a  speeial  purpose  eompiiter  P4.  l'lie  special-purpose  eom|>uter  has  a  dedieated  nienmrv 
M4  which  i*  accessible  via  communication  interlace  l.v 


P  -  processor 
M  -  irteriory 
D  -  device 

E  -  external  interface 
I  -  internal  in  ter  face 

l  ipurc  Sample  problem  multiple  processor  configuration  reflects 
shared/ private  memorv,  processor -to-proeessor. 
and  external  device  communications. 


To  represent  the  process  flow,  the  basic  computational  tasks  relationships  denoted  in  f  igure  10  arc 
u»ed.  I  I  and  T.”>  represent  c  ontrol  coordination  tasks.  Tasks  T2.  175.  Tf.  TO.  17.  and  TH  represemt  task’ 
for  device  I  ).  Simclarlv  tasks  12'.  17 V.  TV.  T<>'.  T7'.  and  I  K'  represent  those-  same  tasks  lor  device- 1 T,.  I  wc 
iteration  rales  (.‘{<1  hertz.  I  hertz)  arc-  reipiirc-d  to  inc-c-l  the  math  model  slahilitv  recpiirc-ineuts.  To  eomph-tc 
the-  computational  tasks  flow  description,  the  task  data  and  instruction  block  requirements  must  lie 
defined  as  desc-rihc-d  in  Section  175.2. 


T1 


T7 


/  ifltirc  10.  Sample  task  flow  indicates  control  task  I  and  .">  with  duplicate  task 
(i.e..  2  and  2'.  etc.)  to  support  the  two  training  positions.  Iteration 
rates  have  also  heen  denoted  as  a  fast  loop  (30/sec) 
and  a  slow  loop  (I /sec). 


\  primary  allocation  of  tasks  to  the  candidate  conf  iguration  can  he  defined  as  presented  in  Section 
1.3.2.  l  itis  allocation  can  then  lie  perturbed  when  necessary  to  study  alternative  design  features.  \l  this 
point,  wc  are  reads  to  discuss  tile  class  of  feasible  tools  and  techniques  identified  during  this  studs  for 
evaluation  of  alternative  candidate  multiple  processor  designs. 


3.3  Feasible  Tools  and  Techniques 

Complex  systems  such  as  flight  simulators  and  other  modern  information  systems  require  important 
planning  decisions  well  in  advance  of  actual  implementation  in  order  to  assure  that  the  system  being 
planned  is  feasible  and  will  attain  its  performance  goals  within  the  available  resources.  Alternative 
candidate  approaches  require  evaluation  as  a  part  of  the  overall  process  of  making  design  decisions 
regarding  eost/perlormanee  tradeoffs. 

Automated  performance  prediction  programs  are  frequently  called  simulators  or  simulations: 
however,  it  is  clear  that  these  programs  are  distinct  from  the  software  involved  in  complete  flight 
simulators.  As  shown  in  the  Table  (>.  automated  performance  prediction  programs  include  several  classes 
of  models,  with  each  class  involving  various  levels  of  complexity  ami  having  various  primary  applications. 
*e  have  found  that  there  i>.  frequently  a  need  to  develop  models  that  include  some  features  of  various 
simulation  (  lasses  in  various  parts  of  the  model  in  order  to  tailor  the  tool  to  the  issue  at  hand. 

I  he  tool  categories  presented  in  Table  0  are  ordered  from  the  most  straightforward  to  highlx 
sophisticated,  special  algorithm-analysis  tools.  In  most  eases,  the  outputs  from  the  more  detailed  tools  can 


I'ihlr  it  (.almoin*.  of  Ih-i*' n  IVrlnrmatirr  Predict mu  !  ools 


\ppli;i(MMi  \  nal\  - 


si;|l ir  |{r-oiir«  r  M.hIi  K 


mil  i snmil,ilH'ii* 


i  -hmafnl  lifiiiiiii  and  -i/in*:  |>rnln  Inm-  lor  prorr--or  utih/ation. 
tnr/mir\  uldi/alnm.  and  nr'UMik  data  ralr-  ha-rd  mi  t  ompulalmnal 
i‘\mii  i  \  r  ii  \i  t  - 1 1  m  i « ■  'Ail*-  tn« nr  |  meat  nij*  itrraiion  ratr-  and  lutu  tional 
f.ok  m mu*'  and  -1/111*1  daia. 

Mndidlm*'  tin*  major  -\-lmn  I  D  loading  and  ronirol  lo^ir  lor  anak-i- 
and  prrdi*  •lion  ol  MM  til  i  I  i/a  I  no  1 .  Imntionul  alloration.  data  flow. 
*  1 1 1  *  *  1 1 1 1 1  drlax-.  rr-oun  *•  n-ap*.  rr-ounr  adoration.  growth  and 
degradation.  and  oxrrali  -\-inn  or*:ani/a1 ion . 


\  n.d\  1  i<  inidat  lon- 


Mal liriiia! H.d  n  jiiv-riilat nm  id  a  -prrifn  aljioril Inn  for  -lnd\in^  their 
aoniiia*  detailed  ln*»ir.  ami  *  *  mi  pill  at  nmal  Uad*ol|-. 

>|M**  i.il  -oil wan*  and/or  hardware  wlm  h  prodmr-  r\art  mm  jmlalnmal 
rc-nlt-.  tin*  mlr  of  -prriali/.nj  hardware  tlial  i-  rurrenik 

mia\ aiialdr.  to  r\n  nlr  m  emulate  an  algorithm  rrjur-rntrd  in  ohferi 
t  od*'  loriuai  Inr  propo-rd  -prriaii/cd  hardware. 


!*<•  irdm  •  *(  fo  fo«.\  idr  relmed  input-  lo  the  -impfitnd  tool-  Ihr  ra-c  or  ditf  iruh\  of  u-inj:  llior  tool-  in  a 
'"Mrlnlmj  ta-hion  i-  din  *  li\  related  In  (In-  •  ■  x I »'  1 1 1  will)  whieh  a  "lohal  data  ha-e  de-if'n  and  tool  l/U 
iiitorfai*  definition-  air  r.><>rd»nalrd.  Thi-  -rriion  rmpha-i/.r-  tin-  di-lim  lion  amuii*»  and  definition  **l 
•Mr|i  ol  liir-r  .inal\-i-  lr\rl-. 

I  aide  ,  rrl  iii  -  liir-r  tool-  lo  tin-  dr-i^n  goal.-  r-lahli-hed  lor  multiple  pioer--or  r.mdidalr  d**-i*;n 

•  valuation  itrhimpn*-.  I  In  -lain  tool-  ran  provide  a  -injile  value  e-timale  lor  mo-l  ol  llir  nira-urmir nl 
*i*»al-  Slain-  1 00 1  —  air  nol  alilr  to  adeipiateh  as-e—  d\  namii  mea-ure-  -m  h  a-  >u-pended  wait  timr.  pori- 
i"  port  1  \ r lr  Imir-.  and  rriln  al  paths  withoiil  -omr  -oil  ol  mlrra«ii\r  inlrrlarr  and  knowledge  id  a 
linn  inm. d  or  anakln  modrl.  I  In*  liinrlnmal  lool-  ran  provide  -tati-lnal  r-innalr-  lot  all  ihr  ha-n 
nira-urinriil  p».d-.  I  linr  \  ;i 1 1 1 1 i f \  1-  -uhjn  i  1  •  •  tin*  lnirlit\  ol  (In*  input-  and  lr\ri  ol  mmpulat  ional  model- 
ulilr/ed.  \nal\ tir  and  riinilation  tool-  jjeneralk  addn*--  a  Milnei  ol  llir  eomputalnmal  -ul»*\*tein  in  l«*rm- 
of  a  -peeifir  la-k  algorithm.  I  or  ihi-  rra-011  iliev  provide  detailed  iii-ij'hi  a-  lo  roinpnlalional  aecuraev 
and  limine  nl  llir  ^iven  al^onlhm  Iml  would  hr  loo  \olunnnou-  and  unwnldv  lo  addn--  (lit*  total 

•  om jnitalional  -u-h-\-t«*m  -laii-tir-.  Heijardles-  «d  ihr  tool  linn*:  utdi/ed.  a  well-defined  design  daia  hast* 
and  report  j'euerator  ran  ^reatlv  -implilv  tin*  u-rr  inlrrlarr  and  roordinalrd  u-r  of  multiple  tool-  in 
I  at  *  r  I  nr  111 1  nj*  <  andidatr  mid  i^iiratinn  evaluation-. 


I  I"'  "I  *-■><  I.  «<»>l  <liriTll\  rrhilr-  In  ihr  ■lain  rnllr,  linn.  .iiMminilrit  proi  nlnr.-y. 

<  oMlipiralinn  ni.in.ipinrnl.  anil  ipialili  a«Mir;mrr  |irn\  i-iim-  Inr  a|)|il\in)!  llir  Innl-.  willi  am  Innl.  llir 
<1 1  la  I  ■  I  \  nl  llir  ■  1 1  |n  1 1  ami  llir  InlrliH  nl  llir  innilrl  ilirrrlK  iiilliirnrr  llir  iiilrr|irrlalinn  n|  ami  rnilfidriirr  in 
tin-  niil|mi.  l*nr  nl  ilm  I <  a- 1 1 > 1 1 1 1 %  i-Mim  min  rriK  ihr  ntiinliiT  nl  run-  rn|iiirnl  In  nlilain  mraninplul 
a,l'"rr'  I'lrm  llv  rrlair.l  in  llir  nninhrr  nl  run-  air  llir  iii|inl  data  ami  (laranirtiir  rmilrnU  nrcrwarj  In 
. . . .  llir  inn-  In  nlilain  a  mraniiifrlid  mlrinrlalinn  nl  nut  iml 


I tihlr  I  ool  (atc^orx  Petal  ioti"hip  %« i t It  t/oal 


|.M,I 

(  ll.tiniN 

1  Ml  11  1  .1 

Desit'ii  <, n;i|s 

1  IJIM  ltnll.il 

Vil.-tlx  li<  *  * 

1  1**11*  ’ 

1.  Predict  processor  utilization  statistic"  with  rented  i<»  tin* 
real-time  exi  le  lo  ilieude: 

•  \ppliealion  task  liming  to  inehidc  iomput.itiou.il. 

N.- 

'lo. 

No. 

1  tela  i  l*-<l 

l/( )  wait. 

N.- 

Nr- 

I’ariial 

Partial 

and  siispemled  wait  time  "tatUtic" 

\(l 

\r- 

I'a.lial 

Partial 

•  Kesoiirce  management  ow  rhead  liming 

'I  r. 

No. 

1 ‘a  dial 

Partial 

•  Spare  Time. 

Nr- 

No. 

I’arlial 

Pa  rl  ial 

2.  Predict  eomnmnieatioiis  traffic  queuin'!  "laiMtC"  with 

res perl  to  real-time  exile  to  include  lm"X.  idle  and  wail 
time."  for: 

*  Channel  uiili/ation 

Parlial 

N  o. 

I’ariial 

No 

•  Interproeessor  transfer" 

Nr. 

No. 

I’arlial 

No 

•  Mi‘in»r\/|tr<M't'i>Mir  Iran-lir. 

Nr. 

No- 

I’arlial 

1  lol.llloii 

•  t  .xele  and  thread  port-lo-port  itmm"  -iati"th  " 

N„ 

No. 

Partial 

No 

1  join  the  stati"tieal  predictions  determine  the  follow  iii*» 
critical  di*"i^n  iv-onrre*  with  respect  to  iui"ati"lied  luuemo 
•indoor  "pare  growth  requirmnuf- 

•  <  ritical  path  1a"k/data  "cipience 

No 

’l  «  " 

Partial 

I’arlial 

•  Potential  bottleneck". 

N  r- 

N<- 

No- 

No- 

1.  Provide  summaries  of  selected  candidate  coni i^uration 
utili/ation.  queuin':  and  critical  resource  >lali"li<"  lor 
which  goal-  1.  2.  and  f  have  been  determined.  Section  1 .2 

provides  lormals  lor  "pciilic  report  miiii nui ri*--  in  I  i«>[ure" 

1 2  through  I  . . 

Data  Ua.se/Kcport  (ienerator  Kecjuired 

>.  l  or  "circled  alternative  candidate  eon! i^uration  provide 
sidr-hv  -"idr  "Ummarie>  nl  selected  statistics  Iroin  ^oal-  1. 

2.  and  .'i. 


M'mh  n|r  a  'injilf  '-•tim.ilr  .I“  «i|i|ni"i*n  In  -l.ili'l  na|  I  'lim.ilr. 

*  in ii li if •!«*  run-  to  obtain 


In  our  experience  with  actual  perlormam  e  prediction  problems.  ur  have  found  that  various 
"iihsvsleni"  of  tlir  svslcm  nerd  to  lit*  modeled  to  i|  if  I  err  ill  decrees  ol  accuracv .  I  hi**  moan**  that  some  of  flic 
"tihsyslem  models  niiist  hr  ftinrlional  models.  and  other"  must  hr  analvtir  models  or  r  run  la  tor".  Proper 
design  and  implementation  of  a  simulator  provide  a  hijzhlv  "tructiired  simulator  with  sufficient  flexibililv 
to  allow  tailoring  each  modulr  to  In*  lunrlional.  analvtir.  or  mixed  as  required  to  support  tin*  overall 
objective",  Thi**  llexihililv  is  important  herati"e  ol  rapid  inere;i"C"  in  tin1  cost  of  development  ami 
operation  a>  more  fidelity  is  demanded.  Tlir  model  must  include  onlv  those  aspects  of  thr  >utnn  that  art* 
relevant  to  tlir  study  objectives.  Optimizing  a  model  to  a  single  svslcm  configuration  is  not  dc"irahlc. 
however.  since  the  lose  in  flexibility  .aiNr*  higher  maintenanee  costs  throughout  tlir  life  of  the 


simulation.  TUT.’-  general  approach  In  (lie  design  of  I  In-  performance  prediction  model  ha-  in<  -hided 
-pedal  attention  In  I  In*  eo-l.  pcrlormam  c.  anil  growth  |inti*nlial  tradeoffs  dial  ari*  useful  III  (In-  planning 
anil  i*\alualinn  nl  rnin|ili*\  (light  training  computational  siibsx  stems. 

Our  design.  presented  in  Section  I.  Incuse-  upon  a  generic  multiple  processor  lunrliniial  simulator 
w  llidt  rail  inlrrlarr  \  ia  data  ba-e  and  manual  selection  with  ntlirr  tools.  Tin*  rrlalrd  I  uni-  with  w  Inch  I  In* 
rnruininriulrd  luurtinnal  simulator  max  mlrr.n  l  art*  nuu  described  with  respect  In  tin*  flight  -linulalnr 
in ii 1 1 1  |>l i *  processor  design  evaluation  rnlr.  These  Inrllulr  static.  analxtir.  and  rniulalinn  Ion!-. 

14. .'4.  I  Sluin'  Meson  roe  4/ode/x.  Sialic  resource  inndrl-  (-uinrlllllr-  railed  "beancounter-  ')  arc 
txpicallx  straightforward  program-  that  -uni  resources  used  as  function-  nl  inputs  involving  re-norco-  per 
rxrrnlinii  and  execution  rale-.  I tepending  nil  tin*  complexity  nl  llu*  sxslcm  being  nmdrlrd.  these  static 
resource  inndrl-  ran  range  from  alnmst  Irixial  In  ipiilr  rninplrx.  Tnr  rxamplr.  1141.  Iia-  developed  and 
ill  1 1  I/rd  a  rninplrx  inndrl  In  I  hi-  rla— .  callrd  <  II.  HI.  which  arrnuntrd  fur  tin*  <  !IM  resources  u-rd  In  a  irri 
sophisticated  operating  sxslem  tnr  tin*  Site  Itrfrn-r  I4alli-lir  Ml— ill*  Sx-lrin. 

TUT!  -  Software  I’arlitinn  Study  rnnlrart  with  MTII4I.  (Ifcference  7)  provided  thr  details  nl  a  -lalir 
rr-nurrr  analx-i-  inndrl  fur  flight  training  -inuilatnr  ruinpiilational  design  partitioning  anali-i-.  This 
analx  sis  tnnl-  requires  manual  intrrartion  Irrliniipirs  In  r-lahli-h  a  liasrlinr  part il jtiu  nl  thr  ruiupulatiunal 
ta-h-  rrlationships  wliirh  art*  indrprndrnl  nl  a  -prrilir  computational  hardware  configuration.  Oner  thi- 
hasrlini*  part itioii  of  tin*  mathrmatiral  model  Iia-  hern  translated  to  eomputational  tasks  and  the  data/ 
timing  relationship  have  hern  established,  the  partitioning  tool  faeililatics  analx-i-  and  allocation 
tradeoff-  for  any  given  candidate  hardware  roufiguralion.  \s  pointed  nut  in  this  related  studx.  the 
allocation  of  a  given  computational  partition  is  a  mathematical  optimization  problem.  The  filial  report  fur 
the  Software  Partitioning  Studx  documents  the  optimization  model  and  a  heuristic  design  for  its 
implementation  a-  an  automated  design  aualvsix/eialnation  tool. 

\  major  emphasis  fur  this  mol  i-  the  dexelopmeul  of  a  flight  training  computational  design  repo-iiory 
which  would  great!)  facilitate  liming  and  -izining  estimates  during  tin*  preliminary  design  phase-  of  a  new 
training  simulator.  In  addition,  the  tool  facilitates  exaluation  of  proposed  design  changes  and  tradeoff-  to 
an  existing  facility  prior  to  change  implementation.  T  in*  data  base  structures  defined  hx  the  partitioning 
tool  provide  a  means  for  ttnanihiguouslx  expressing  lask/data  flow  relationships.  Il  also  provides  for  the 
separation  ol  hardware  technology  timing  and  sizing  attributes  I  rum  the  computational  task  description- 
via  the  establishment  of  a  lechnologx  data  base.  I  sing  this  technitpie.  a  task  i-  described  in  term-  ol  a 
standardized  macro  instruction  mix  which  can  than  he  autumaticallx  translated  to  specific  timing  and 
-iziiig  lor  a  given  proces-or/memorx  configuration. 

l  lu*  extensive  partitioning  data  base  combined  with  a  processing  allocation  and  the  coni iguration 
communication  priority  schemes  Inrm  the  major  inputs  needed  to  drive  a  functional  simulation  of  a 
generic  multiple  processor  model.  The  processing  allocation  ol  tasks  to  processors  and  data  blocks  to 
memories  is  tin*  major  output  ol  the  I’arlilioning  Mgorilluu.  The  interpretation  of  tin*  configuration 
rommuniealion  rules  and  processing  priorities  i-  the  major  emphasis  of  the  lunetinual  simulation  tool 
defined  hx  this  contract  in  Section  I.  The  two  tools  are  part  of  an  iterative  design  evaluation  Iradeofl 
process  to  predict  candidate  configuration  performance. 

!4.!4.  I  mi/vtii  Simulation  Ifo  defx.  The  term  anal)  lie  simulator  is  I  v  pica  1 1  x  used  to  describe 
simulators  that  contain  mathematical  computational  algorithms.  These  simulators  are  usuallx  used  to 
-tudv  the  aecurai  x  and  detailed  logic  behavior  of  an  algorithm.  Tor  example.  114 17  has  ileveloped  and 
utilized  analxtic  simulators  for  detailed  studies  ol  tracking  filler  algorithms  and  radar  scheduler 
algorithms.  In  general,  analxtic  simulators  do  not  model  systemwide  timing  and  tpteing  considerations: 
however,  load  and  liming  considerations  are  important  in  selecting  which  algorithms  to  emphasize  in  the 
analvsis.  \nalxtic  models  ustiallv  require  realistic  input  data.  These  simulators  are  most  useful  lor  studies 
requiring  detailed  compulations. 


In  tin-  ea-e  ill  flight  training  simulator-.  there  an-  mam  iiunirriral  analx-i-  tradeoff  tli-i  i'ioii-  xxhieh 
require  a  high-lidelitx .  imn-rral-liiiir  mathematical  algorithm  In  -ludx  relationship-  of  ~ | >< -<  i f  i<  aircraft 
hodx  ami  weapon  -x-lem-  malli  model  contiguralion  responses.  Txpieallx  these  analxlie  malli  model-  arc 
enumerated  in  l-'OKTU \\  lor  large  mainframe  computer-.  Tltex  ran  prox  idc  a  lairlx  efficient  inran-  for 
delineating  or  xerilxing  n«*v%  algorithm  computational  logic  and  accnraex. 

In  general,  llie-e  models  rrijiiirr  drlailrd  data  lor  tin*  specific  ainral t/weapon  -x-fcin  recorded 
performance  measurement-  Irom  rontrollnl  Might  lest  rin  iroumenls.  The  hasclinc  application  load 
require-  drlailrd  inilial  -lair  saint-.  flight  profile.  and  time-lagged  weapon-mode  actixatiuu  -witelie- 
xx lurli  corrrlatr  with  ill r  flight  profile.  Ilx  rarelnl  jiarainrlrri/alion  and  inallirinatiral  modularization.  thi- 
analxlie  inotlrl  rail  hr  used  In  refine  estimates  of  -rlrrlrtl  computational  niotlulr  partitioning  la-k 
parameter-  ami  pro i  i dr  -lati-liea)  distribution-  lor  Inm  lional  timing  and  queing  size-.  I  lir  utilization  ol  a 
nnn-rral-limr  model  permit.-  t  onrrn'ra'rd  unalx-i-  td  llie  required  high-level  computational  iii-trnetinn 
in i n .  control  sequence  logic,  and  art  nr...  \  nl  a  candidate  algnrillnn.  I'hex  plax  an  important  role  in  math 
inotlrl  requirement-  in  term-  nl  determining  real-time  iteration  a-  a  lum  tion  nl  integration  slop  size  a- 
xxell  a-  pros  itlmg  detail  ilr-ign  hardware  and  language  -eleelion  lealnre-. 

l.tniihiloi'i.  The  Irrm  rmnlalnr  u-nall\  refer-  to  an  in-truetion-lcxcl  -inuilalinn  of  another 
computer  in  order  In  duplicate  the  proers-ing  nl  llial  ctunpulrr.  I. initiation  can  hr  acrompli-hctl  through 
-oil ware  technique-  or  h\  u-ing  micro-code  to  program  a  microprocessor  lo  interpret  the  instruction  -el  ol 
the  target  computer  and  duplicate  the  output  of  the  proer— ing  initialed  In  a  command.  I'.mulalor-  ol  thi- 
I \  pe  arc  mils  u-ed  when  extreme  computational  fidelitx  i-  reipiircd  and  where  l lie  actual  software 
instruction-  arc  available. 

Kmulalion  i-  gcncrallx  rc-erxed  for  making  tradeoff-  in  new  hardware  technologx  area-  where  the 
pmtotx  pe  hardware  and  support  software  <ln  nut  currentlx  exi-l.  I'hex  max  also  he  employed  to  determine 
the  impact  of  a  modified  nr  extended  iu-lruetion  -el  prior  to  luiilditig  a  prototype.  In  the  llight  training 
computational  -uh-x-lem  cxaluatiou.  certain  henchmarh  algorithm-  arc  scfecteif  for  ending  in  the 
propn-cd  machine  language  and  then  the  code  i-  emulated  (executed)  with  diagnostic  dump-,  di-plax-. 
anil  printout-  to  determine  it-  performance  in  term-  of  timing,  -izittg.  and  arruracx.  The  benchmark 
algorithm-  are  restricted  In  a  da—  nl  ta-k  computational  characteristic-  for  xx liich  the  proposed  instruction 
architecture  i-  reportedlx  well  -oiled  nr  dc-igned  In  handle. 

In  main  iu-lame-.  the  -ollware  and  hardware  nece-sarx  to  support  a  llexihle  emulation  ti-er 
interlace  co-t-  more  than  it  would  to  luiild  a  prototxpe.  Thi-  i-  partieularlx  true  in  the  evaluation  ol  anx 
radirallx  different  in-tructinn  -el  architecture.  \t  the  other  extreme,  the  actual  hardware  max  exist.  Iml 
xex  little  development  and  diagnostic  support  tool-  exist.  ( 1  hi-  i-  partieularlx  true  with  mieroprncr— or 
technologx.)  In  this  situation,  a  mini-computer  max  provide  a  lull  complement  ol  cross-compilers.  - 
assemble r-.  -link  editors,  and  emulator-  lor  algorithm  development  and  inilial  debugging  prior  lo 
downloading  the  object  code  or  burning  the  HUM-  lor  the  object  computer.  In  thi-  latter  situation, 
emulation  i-  a  le-t  tool  rather  than  a  de-ign  tool,  although  real-time  critical  new  algorithm  de-ign  could 
cmplox  the  -ante  tool-  to  pnr-uc  detailed  Iradcoll-  a-  nece— arx. 

In  -ummarx.  a  xarictx  ol  automated  technique-  are  not  onlx  feasible  but  Itaxe  been  applied  in 
specialized  design  ex  alualiou  -riling-.  I  he  lea-ihle  adaptation  ol  a  general  -rt  xd  multiple  processor  de-ign 
evaluation  tool-  i-  direcllx  linked  to  requirement-  and  de-ign  -predication  standard-  lo  facilitate  a 
qualilx  -controlled  automated  data  cnlrx /reduction  process.  Sialic  tool-  -neb  a-  the  Partitioning  Mgorilhm 
provide  -x-lemalic  arcounlahililx  of  a  diver-e  number  of  inlerrrrlatrd  reqiiiremeuls.  design,  hardware, 
and  software  parameter-,  functional  -Mutilation  tool-  cxrrri-r  the  operating  rule-  and  coinmnnicalion 
rule-  to  carrx  out  ta-k  sequence-  and  data  dependencies,  \nalxlir  and  emulation  tool-  arc  reserved  lor 
specific  new  algorithm  mathematical  and  implementation  Iradrofl-.  re-pectixelx .  I  rom  these,  the 
functional  simulation  wa-  -elected  lor  detailed  expansion  a-  it  he»l  meet  the  de-ign  goal-  lor  a  generic 
multiple  processor  performanee  model 
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"‘IR  -ENT  -SECCNO  r*e-C FM  iEC  CNlTS 


REQUIRED  ‘iRARf 
n  or.  p:  n  r 
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lartlitaU'^  a  quirk  look  evaluation  oi  *»|iar»*  utilization 
ami  |M'o\i<ii's  a  means  (or  f faifixiiijj  erilieai  <lrsi£jii  ruii)|H>nents 
near  or  above  required  yrowlli  f.iclur  lor  tf i \ « ■  •  •  ^irntihilion  load. 


major  i  nmpoin  iil  i-  iblri  miiim-il  In  I"  .1  problem  ansi  wlii'li  r.  ijiim  -  ailditnin.il  anaU-i-. 
linin'  <1,1. nil'll  tnmpninilt  report-  bare  In  i'll  ili-~i” in-il  In  In Ip  nlt-nlil  \  tin-  1 11 .1 1  li - 11  it k -  I  ln*-i*  repnrl-  an* 
lailiin-il  In  tlm  11  >  1 1 1 1  >1  >i  1 11 1 1  rali'fini  \  a-  illn-lialeil  in  I  idlin'  I  I  ami  I  I  Inr  pm<  c— or  nlili/alimi  ami  I  ijjnrr- 
I  ."1  ami  lit  Inr  meiunrx  nlili/almn  ll  1-  im|mrlafil  In  nnli*  llm  -lali-ln.il  -11111111. ir\  lin  Irrin-  nl  iiiimiImt  "I 
tilin'-  a  nj  \  mi  rvi’iil  occurred.  -mil  a-  an  application  I  II  ii'i|ni'-l.  alnnn  nilli  niiniiiiinii.  ma\  1  nnnn 
;n,'r;ij!i'.  anil  -lamlaril  deviation  -lali-ln  -  Inr  tin-  |iari n  11l.11  nn'a-iiri*iin*nl I  provide-  «l\ tiiinm  rari«i'  ami 
\  arianri*  nl  -injxli'  mea-urrnienls  with  re-peet  In  apphialinii  ri'-nurn*  r  *  *  1 1 1  n  r  1  ‘  1  n  1  *  1 1 1  nii'a-iii'i'nii'iil-  -m  li  i- 
la-lv  1‘M'i'til if »n  1-  ami  ilala  Idnek  -Inrajie/reirieval  paraiiieier -. 
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PROCESSOR  Derail  ED  TASE.  MU  FOR  PROCESSOR  PPPPPP  DEVICE  DDDDDDDDDD 


IAS* 

10 


EXECUTIONS 

STARTCO 

COMPLETED 


TTTTTT  999999 
999999 


- TO  l  Al  — 


MEAN 

MAX 


. . TIMING  STATISTICS  PER  COMPLETED  EXECUTION  IN  MIUISIC  . . 

REQUIRED  - COMPUTATIONAL - - 1/0 .  - . SUSPENDED . 

MIN  MEAN  MIN  MEAN  MIN  MEAN 

MAX  S  0EV  MAX  S  DEV  MAX  S  DEV 

999 .99999  999.999999  999 .999999  999.999999  999.999999  999.999999  999.999999  999.999999 

999. 999999  999.999999  999.999999  999.999999  999.999999  999.999999  999  999999 


lifSinr  II.  I’riiirsMir  iilili/alinit  ilflaili'il  task  Hlix  r«-|M»rt 
is  (b'sijiiii'jl  In  present  application  task  limiiifl  statistics 
plus  11 11 111  Imt  nf  cxcculinns  started  and/or 
cninplctcil  Inr  the  simulated  period. 
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MEMORY  UTILIZATION  BY  PROCESS  I/O  REQUEST 


MEMORY 

DEVICE 

ID 

PROCESSOR 
DEV  ICE 

10 

REQUEST 

TYPE 

--SIZE  IN  UUUUUUUU  OF  999  B1TS- 

—  PER  REQUEST . TOTAL - 

MIN  MEAN 

MAX  S  DEV 

-SERVICES  TIME  IN  MICRO 

- PER  REQUEST . 

MIN  MEAN 

MAX  S  DEV 

SECONDS  — 
--TOTAL-- 

BASIC 

ACCESS 

TIME 

(NSEC) 

MMMMMt 

0000000000 

PPPPPP 

DD00000D0D 

REA0 

9999999 

9999999 

9999999 

9999999 

999999999 

99999 . 9999 
99999.9999 

99999 . 9999 
99999.9999 

999999999 . 

9999. 

WRITE 

9999999 

9999999 

9999999 

9999999 

999999999 

99999.9999 

99999.9999 

99999.9999 

99999.9999 

999999999 . 

9999 . 

TOTAL 

9999999 
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I'ipmi’  /■>.  Memory  utilization  by  processor  report 
permits  identification  of  processor/ memory 
access  bottlenecks  in  terms  of  wait  times  and 
required  service  times. 
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l  ipurr  ! (t.  Application  data  block  summary  permits  sizing  and 
storage/ retrieval  timing  to  be  analyzed  for  potential 
design  reorganization  if  critical  wail  time 
bottlenecks  are  detected. 
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In  summary  component  level  measurements  output  by  the  model  include  the  following: 

1.  Component  busy/idle  measurements  for  given  evaluation  time  period. 

2.  Processor  utilization  in  terms  of  resource  management  overhead,  application  task  mix 
(computation.  I/O.  and  suspend)  services  and  idle  periods. 

Memory  utilization  in  terms  of  processor  communications  and  in  terms  of  data  block 
communications  including  types  of  accesses  and  number  of  accesses  in  addition  to  measures  of 
service  and  wait  times. 

4.  Communication  link  utilization  parameters  in  terms  of  total  traffic  throughput  and  wait  times 
by  interfacing  devices. 

In  addition  to  configuration  components,  external  device  I/O  responses  require  that  the  system 
throughput  for  given  inputs  be  traced  via  the  model  to  determine  associated  response(s)  times.  In  the  real¬ 
time  flight  training  environment,  training  device  outputs  are  extrapolated  based  upon  a  combination  of 
input  samples,  aircraft  and  weapon  system  models  plus  other  environmental  and  equipment  specific 
models.  Thus,  a  single  input  source  is  seldom  directly  traceable  to  a  given  output  response.  Instead,  the 
software  design  real-time  cycle,  subcycles  and  frames  become  the  important  synchronization  of  frame, 
sub-cycle,  and  cycle  computational  support  completed/uncompleted.  In  particular  sequentially  dependent 
software  task  threads  within  each  of  these  levels  must  meet  appropriate  timing  requirements.  The  model 
is  designed  to  track  and  summarize  related  task  timing  data  in  terms  of  busy  versus  idle  statistics  for  four 
different  iteration  rate  subcycles  incorporated  to  define  a  real-time  cycle.  It  also  accumulates  end-to-end 
timing  statistics  for  20  dependent  task  threads.  A  sample  output  format  is  illustrated  in  Figure  17.  These 
dimensions  ran  he  increased  given  that  adequate  storage  is  available  for  the  many  variables  used  to  track 
and  accumulate  the  statistics. 
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Figure  17.  Application  throughput  outputs  are  modelled  for  at 
least  four  levels  of  software  iteration  rates  and  20 
different  threads  to  obtain  end-to-end  timing  statistics 
for  comparison  with  required  time  limits  and  built  in  spare. 


Tabular  report  outputs  are  not  the  only  convenient  means  for  consolidating  and  presenting  the 
simulated  performance  parameters.  Histograms  can  provide  a  visual  comparison  of  parameters  measured 
at  given  periodic  intervals  over  the  simulated  evaluation  time  period.  Figure  18  is  an  illustration  of 
processor  utilization.  The  types  of  reports  and  displays  which  can  be  generated  are  many;  however,  the 
basic  output  parameters  remain  the  same.  These  parameters  are  defined  in  Appendix  A. 
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PROCESSOR  UTILIZATION 
VERSUS  CYCLE 


4 

*  T 

u  L 


Figure  18.  Histograms  of  various  parameters  such  as  processor 
utilization  provide  a  visual  means  of  the  load  balance 
among  processors  and  peak  cycle  or  frame  loading  with 
respect  to  the  simulated  evaluation  baseline  load. 


4.3  Model  Inputs 

The  amount  of  input  parameters  necessary  to  obtain  the  outputs  is  directly  related  to  the  selection  of 
hardcoded  models  versus  generic  data  driven  models  incorporated  in  a  discrete  event  simulation  model. 
Generic  models  by  their  very  nature  require  more  data.  but.  as  a  general  rule,  permit  a  wider  range  of  user 
problems  to  be  analyzed  in  a  parametrically  controlled  data  environment  without  changing  the  model 
code.  On  the  other  hand,  a  hardcoded  analytic  model  may  be  a  more  precise  representation  of  the  given 
entity  under  study. 

In  the  case  of  flight  training  simulator  computation  configuration  evaluation,  there  is  generally  an 
abundance  of  data  and  design  documentation  descriptions  which  must  be  sorted  out  and  reviewed  for 
completeness  of  the  design  specification,  as  well  as,  ascertaining  if  the  design  will  satisfy  the  training 
computational  interface  requirements.  Therefore,  candidate  design  evaluation  is  primarily  analysis  of 
supplied  data  permitting  the  feasibility  of  a  generic  evaluation  model.  The  model  has  been  designed  to 
provide  an  organized  method  for  extracting  and  entering  the  data  to  automate  evaluation  of  the  more 
complex  relationships  which  must  be  satisfied  by  the  candidate  design. 

In  organizing  the  inputs,  the  following  have  been  used  as  the  major  areas  of  data  collection/entrv. 

1.  Computational  Interface  Requirements 

2.  Candidate  design 

3.  Baseline  load 

4.  Technology  data  base 

5.  Evaluation  options. 


. . .  . — 


44 


A  brief  observation,  with  regards  to  the  software  partitioning  data  base  (Reference  7)  and  its 
relationship  to  the  performance  prediction  model,  is  now  given.  The  computational  interface 
requirements  are  the  same.  The  candidate  design  area  contains  the  resultant  software  partitioning 
allocation  (or  a  manual  candidate  design  allocation  if  simulation  is  run  independent  of  partitioning)  of  the 
baseline  software  task  for  a  given  candidate  configuration.  The  baseline  load  is  a  combination  of  the  static 
partitioning  software  task  load  parameters  plus  additional  dynamic  load  distribution  parameters.  The 
technology  data  base  remains  the  same.  The  evaluation  model  options  are  an  expansion  of  the  software 
partitioning  evaluation  parameters  to  permit  parametric  model  controls  and  output  report  selection.  Each 
input  area  is  now  addressed  as  it  specifically  applies  o  the  computational  simulation  performance 
evaluation  model.  Specific  input  parameters  for  each  of  these  five  data  base  areas  are  listed  in  Appendix 
B. 

4.3.1  Computational  Interface  Requirements.  Computational  interface  requirements  provide  the 
inputs  necessary  to  model  the  external  device  interfaces  with  the  computational  subsystem  to  be 
simulated.  Definitive  quantitative  requirements  provide  the  basic  foundation  for  both  system  design  and 
system  modelling.  As  a  minimum,  all  required  external  system  I/O  interfaces  must  be  specified  along  with 
the  system  functions  to  be  performed.  Table  B-l  of  Appendix  B  presents  the  interface  requirements 
inputs  as  three  major  groups  of  parameters;  namely: 

1.  Group  1  —  System  Requirements  Identifier  provides  unique  identification  of  the  system 
under  consideration. 

2.  Group  2  —  System  Interface  Requirements  address  the  number  of  devices  and  required 
options  such  as  I/O  service  frequencies,  buffering  parameters,  etc.  These  parameters  are 
correlated  with  the  technology  data  base  described  in  Section  4.3.4. 

3.  Group  3  —  System  Function  Requirements  address  the  number  of  system  functions,  specify 
function  execution  rate  and  timing  requirements,  maps  system  interfaces  serviced,  nd  defines 
function  to  function  interfaces. 

The  version  of  the  algorithm  designed  under  this  contract  utilizes  system  function  requirement 
inputs  as  a  manual  step  to  obtain  software  load  and  task  definitions  of  the  candidate  design.  The  system 
interface  definitions  provide  the  external  sources  that  the  candidate  configuration  must  service.  Future 
model  expansions  could  provide  an  automated  means  for  traceability  between  system  level  modelling  and 
computational  design  detailed  modelling. 

Referring  to  the  sample  problem  stated  in  Section  3.2,  there  are  eight  defined  external  interfaces  Ej, 
E2  .  .  .  .  E8.  Figure  19  represents  the  input  form  designed  for  external  interface  device  definitions.  Note 
that  each  device  must  be  either  a  communication  link  CL,  Processor  Unit  PU,  or  Memory  NM. 

4.3.2  Candidate  Design  Allocation.  The  design  allocation  parameters  (Table  B-3  of  Appendix  B) 
include  the  candidate  multiple  processor  configuration  definition  with  processor  software  task  and 
memory  data  block  assignments  plus  the  static  lask/data  block  I/O  partition  relationships.  This  is 
essentially  a  consolidation  of  the  baseline  software  tasks,  candidate  hardware  configuration,  and  an 
allocated  partition  organized  in  the  following  groups  as  input  to  the  model. 

1.  Croup  I  —  Design  Identifiers  permit  traceability  to  specific  data  origination  for  this  particular 
design  allocation  to  include  an  indicator  of  manually  generated  versus  software  partition 
algorithm  generation. 

2.  Croup  2  —  Basic  Design  Parameters  provide  for  dynamic  sizing  of  the  simulation  control 
tables  and  event  attribute  files  for  simulation  model  bookkeeping. 
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3.  Group  I  —  Configuration  Components  define  the  processors,  memories,  external  devices  nd 
communication  links  which  comprise  the  multiple  processor  configuration  to  be  modelled. 

4.  Group  4  —  Data  Block  Attributes  and  Allocation  provide  the  means  for  defining  data  set 
storage/ retrieval  discipline  fur  processor/memory  communication.  The  attributes  supplied  are 
correlated  with  technology  data  base  storage  definition  parameters  and  memory  assignment 
and  sizing  allocation  to  a  given  block  of  a  memory  storage  device  of  the  candidate 
configuration. 

5.  Group  5  —  Task  Definitions  and  Allocated  Processor(s)  provide  detailed  timing,  sizing.  I/O 
interfaces.  I/O  volume,  and  enablement  criteria  for  each  task  including  assigned  processor(s) 
and  instruction  block (s)  memory  assignments.  A  major  emphasis  is  definition  of  the  design 
communication  rules  for  tasking  and  priorities  for  handling  competing  processor,  memory, 
and  externa!  devices  I/O  communications  w  hich  will  interface  with  the  simulated  load  models. 

Four  input  forms  (Figures  20  through  23)  have  been  designed  to  provide  a  means  for  consolidating 
the  manual  recording  and  data  entry  process.  It  should  be  noted,  that  our  flexible  design  incorporates 
automatic  counters  for  the  basic  sizing  parameters.  These  include  the  number  of  processors,  memories, 
data  blocks,  instruction  blocks,  communication  links,  tasks,  and  other  countable  entries. 
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Figure  20.  Configuration  component  definition  ia  designed 
to  be  input  the  same  as  required  components. 
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Figure  21.  Data  block  definition 


Figure  22.  Task  definition*. 
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Figure  23.  Allocation  inputs  for  allocation  and 
memory  data/instruction  block  storage. 


4.3.3  Baseline  Load.  The  baseline  load  is  the  means  of  representing  the  computational  subsystem 
external  environment.  The  basic  underlying  organization  is  a  training  exercise  timeline  of  external  I/O 
activities  and  the  identification  of  the  required  computational  paths  to  be  simulated  and  evaluated.  The 
following  groups  of  Table  B-4  Appendix  B  were  designed  to  facilitate  load  from  the  steady  state  mix  to 
more  intricate  I/O  relationships  of  the  real-time  environment. 

1 .  Group  I  —  Baseline  Load  Identification  provides  a  unique  label  for  all  the  simulation  run 
results  plus  the  evaluation  timeline  duration  in  terms  of  a  start  and  stop  time. 

2.  Group  2  —  Statistical  Model  Initialization  permits  definition  of  the  statistics  to  be  collected, 
frequency  of  collection,  and  random  number  generator  seed  values. 

3.  Group  3  —  Master  Sequences  permit  a  task  loading  to  be  defined  as  groups  of  data  arrivals, 
cycles  and/or  threads  which  are  scheduled  to  begin  and/or  end  at  some  point  in  the  simulated 
time  line. 

4.  Group  4  —  Data  Arrivals  permit  data  specific  paths  to  be  modelled  and  evaluated  for 
potential  queuing  problems  such  as  processing  delays  and  lost  records. 

5.  Group  5  —  Data  Processing  Cycle  parameters  describe  a  group  of  task  or  task  threads  which 
must  be  executed  at  a  given  time  enablement  frequency. 

6.  Group  6  —  Data  Processing  Threads  permit  a  sequence  of  dependent  tasks  (which  generally 
perform  a  given  I/O  transformation)  to  be  defined  which  may  be  triggered  via  a  master 
sequence  or  a  cycle  within  a  master  sequence. 

Additional  design  details  for  a  given  implementation  are  necessary  before  a  complete  set  of 
recommended  input  forms  can  be  drawn  up.  This  is  especially  true  for  statistical  collection  options.  As  a 
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simple  example,  the  basic  size  of  the  candidate  configurations  being  evaluated  has  a  direct  influence  on 
the  sizing  for  statistical  data  collection.  A  small  (three  processor,  one  memory,  fifty  task)  system  versus  a 
larger  (twenty  processor,  ten  memory,  three  hundred  task,  four  hundred  block)  system  influences  the 
data  structure  and  selective  options  necessary  to  provide  meaningful,  organized  statistics  collection.  For 
small  systems  (generally  a  subsystem  analysis)  it  may  be  most  economical  to  collect  and  reduce  statistics  as 
part  of  the  functional  simulation.  For  larger  systems  a  statistics  log  may  be  output  and  then  reduced  in 
subsequent  postprocessing  report  generators  to  extract  desired  data. 

The  time  tagged  data  is  more  straight  forward.  The  master  sequence  may  be  represented  utilizing  the 
form  in  Figure  24.  This  is  complimented  with  appropriate  Data  Arrival  forms  (Figure  25),  Data 
Processing  Cycle  Forms  (Figure  26),  and  Data  Processing  Threads  (Figure  27). 


DYNAMIC  LOAD  IDENTIFIER  Li  l.±.  ■ 


'  1  '  i  ■  1—1 


MASTER  SEQUENCES 


SEQ 


START 


STOP 


TYPE 

(CIRCLE  ONE) 


IDENTIFIER 


1 

2 

3 

S 

« 

7 

10 


1  11  1  1  1  1_  1  •  1  1 

D  C  T 
D  C  T 
D  C  T 
D  C  T 
OCT 
OCT 
D  C  T 
D  C  T 
D  C  T 
D  C  T 


Ljl 


lx 

Ljl 

La. 

Lx 

Lx 

Lx 

Lx 

Lx 

Lx 


_ L 


xXx 


xJL 


_L_1_ 


x-L 


_ 1 _ 


xxJ 


xxJ 


nl.,.,1  1 


XX 


xxJ 


Figure  24.  Master  sequence  timeline. 


Figure  26.  Processing  cycle  definition. 
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Figure  27.  Processing  thread  definition. 


4.3.4  Technology  Data  Base.  To  assure  uniform  modelling  and  evaluation  of  various  alternate 
candidate  configurations,  an  up-to-date  technology  data  base  is  essential.  Recommended  technology 
attributes  are  grouped  as  follows: 

1.  Group  I  —  Technology  File  Identifier  permits  identification  and  verification  of  specific  file 
being  used  for  technology  parameters.  Thus,  multiple  files  could  be  established  by  various 
user  organizations. 

2.  Group  2  —  Master  Technology  Categories  provides  for  identification  of  both  general  purpose 
and  special  purpose  devices  by  categories  such  as  processors,  communication  link,  cockpit 
controls,  etc.  A  tentative  list  has  been  given  in  Appendix  B,  Table  B-5.  For  each  category,  the 
number  of  entries  are  currently  defined,  and  a  master  identifier  for  each  category  is 
maintained. 

3.  Group  3  through  (TCNC+2)  represent  the  specific  parameters  in  each  of  the  TCNC  respective 
technology  categories.  These  parameters  have  a  direct  relationship  with  the  model  capacity 
and  fidelity.  They  are  subject  to  refinement  as  details  evolve  for  any  specific  model 
implementation. 

Table  B-5  represents  minimal  features  which  may  be  modularly  expanded  as  additional  model 
technology  capabilities  are  defined.  The  generic  handling  of  the  other  inputs  (defined  above  via 
appropriate  identifiers)  permits  the  user  to  set  up  a  variety  of  configurations  without  having  to  script  all 
the  detailed  attribute  data  once  a  given  device  has  been  defined  in  the  data  base. 

A  set  of  recommended  input  forms  to  describe  processors  is  illustrated  in  Figures  28  and  29.  Memory 
device  parameters  are  grouped  in  Figure  30.  Communication  link  definition  form  is  presented  in  Figure 
31. 


52 


Figure  30.  Memory  device  definition  sizing  and  timing  features. 
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Evaluation  Options.  To  facilitate  computational  configuration  design  evaluation  analysis,  this 
area  of  user  inputs  provides  the  basic  evaluation  user  interface  once  the  files  for  the  areas  described  above 
have  been  established.  The  three  groups  which  comprise  this  input  area  (Table  B-6)  permit  proper  run 
quality  and  configuration  controls,  modelled  load  or  design  parameter  changes,  and  required  limits  for 
spare  and/or  task  related  execution  times.  Group  definitions  include: 

1.  Group  I  —  Evaluation  Run  Identification  provides  the  user  a  means  of  identifying  and 
verifying  that  the  proper  files  for  interface  requirements,  technology,  candidate  design,  and 
baseline  load  databases  are  being  used  for  a  specific  evaluation  run. 

2.  Group  2  —  Evaluation  Options  facilitate  a  streamlined  setup  for  parametric  study  runs  to  aid 
in  determining  the  performance  tradeoffs  and  potential  growth  limits  of  the  design  under 
evaluation.  At  the  completion  of  a  detail  design  there  are  still  unknowns  in  timing  and  sizing 
estimates.  These  options  permit  cycle  iteration  frequencies,  data  arrivals,  task  timing,  and/or 
data  volumes  to  he  increased  or  decreased  for  a  given  evaluation  run  to  help  obtain  a  handle 
on  the  candidate  design  sensitivity  to  various  loads. 

3.  Group  i  —  Required  Measures  provide  a  means  for  denoting  processor,  memory  and 
communication  channel  performance  utilization  with  respect  to  growth  requirements  as  was 
illustrated  in  the  output  parameters  via  flagged  report  items.  Also  included  in  this  group  are 
task  cycles  and/or  threads  for  which  throughput  measures  are  to  be  collected  with  respect  to 
evaluator  specified  times. 

The  specific  evaluation  environment  must  he  addressed  in  order  fer  a  set  of  meaningful,  useable  forms 
■•an  he  established.  Therefore,  input  forms  for  this  area  have  been  left  as  an  implementation  design 
decision. 

1.1  Processes 

Several  existing  performance  measurement  simulations  were  surveyed  to  initiate  a  list  of  desired 
design  features  and  models  to  he  incorporated  as  is  or  as  model  candidates  to  be  modified  or  expanded  in 
the  design  of  tile  computer  performance  predictor  simulation  model.  Simulations  which  were  studied 
include: 

1.  SAINT  —  Systems  Analysis  of  Integrated  Network  of  Tasks  from  the  Aerospace  Medical 
Research  Laboratory.  AFSC  WPAFB 

2.  DPSIM  —  Data  Processing  System  Simulator  from  TBE 

3.  CRAM  —  Critical  Resource  Analysis  Model,  including  data  processing  and  C3  models,  from 

TBK. 


All  of  these  simulations  are  FORTRAN  based.  The  first  two  are  derivatives  from  the  GASP  simulation 
language.  The  third  (CRAM)  is  based  on  TBE's  simulation  language.  MODELER.  Both  GASP  and 
MODELER  facilitate  discrete  event,  continuous  event,  and  dynamic  file  management  features  described 
in  the  following  design  process  descriptions.  All  of  these  simulators  incorporate  generic  models  and 
flexible  user  interfaces  to  support  a  variety  of  analysis  modelling  needs,  statistical  collection,  and  quick 
look  report  formatting. 

Each  has  specific  models  which  are  the  results  of  specific  simulation  modelling  applications.  SAINT 
users  have  expanded  upon  the  man  machine  interface  models.  DPSIM  emphasizes  modelling  of  multiple 
processor  resource  management  rules  fur  multitasking  real-time  application  environments  under  various 
open  loop  and  closed  loop  load  scenarios,  (ill AM  addresses  conceptual  man  machine  environments  with 
specific  models  for  constructing  and  analvzing  alternative  communication  networks  and  data  processing 
network  configurations. 
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It  was  determined  that  no  one  simulator  has  all  the  desired  feature1  or  models  desired  for  the 
multiple  processor  performance  predictor  simulator.  However,  any  one  of  these  could  he  adapted  and 
expanded  to  provide  a  flight  training  simulator  multiple  processor  design  performance  prediction 
evaluation  tool.  Our  design  has  remained  independent  of  an  existing  simulator  to  permit  the  delineation  of 
specific  model  processes  necessary  to  meet  the  design  goals. 

We  now  describe  the  processes  necessary  to  transform  the  inputs  of  Section  4.3  into  the  output  of 
Section  4.2.  These  are  grouped  into  three  major  steps  of  the  computational  design  performance  predictor 
model  (as  defined  in  Figure  32):  namely,  initialization,  computational  subsystem  simulation,  and 
summary  report  generation.  The  simulation  step  is  the  heart  of  the  processing  and  is  described  in  more 
detail.  As  will  be  evident  in  Section  4.4.1.  the  required  input  initialization  and  output  report  summary 
processes  are  a  function  of  respective  model  input  and  output  parameters  chosen  for  a  given 
implementation  evaluation  environment. 


Figure  .32.  Three  major  model  processes  are  initialization, 
simulation,  and  report  generation. 


Table  8  summarizes  the  basic  software  modules  which  comprise  the  Computational  Performance 
Predictor  Simulation  Model  (CPPS).  The  modules  have  been  categorized  into  the  major  functional  areas 
of  initialization,  simulation  control,  application  model  events,  candidate  hardware  events,  statistical 
collection  and  end  simulation.  The  design  considerations  for  each  of  these  functional  areas  are  now 
presented.  The  initialization  and  end  simulation  functional  areas  have  been  consolidated  into  data  base  1/ 
O  features. 


Table  8.  Computational  Performance  Predictor  Simulator 
Model  Modules 


Major  Function 

PPD 

Module 

Mnemonic 

Description 

Initialization 

1000 

CPPSl 

Input  and  initialization 

1100 

CP1EO 

Process  evaluation  options 

1200 

CP11R 

Process  computational  interface 
requirements 

1300 

CP  IDA 

Process  candidate  design  allocation 

1400 

CP1BL 

Process  baseling  load  inputs 

Simulation  Control 

2000 

CPPS2 

Discrete  event  simulation 

2100 

CP2DM 

Event  trace  if  debug  monitor  on 

2200 

CP2EV 

Perform  next  event 

Application  Model  Events 

3100 

PULCEN 

Application  load  pulse  generator 

3300 

AKRVL 

Application  pulse  arrival  into  a  given 
queue 

3500 

LEAVQ 

Application  pulse  removed  from  given 
queue  for  servicing 

3700 

PEXIT 

Application  pulse  service  completed 

Candidate  Hardware  Events 

4000 

PROCCK 

Processor  event  state  change  rules 

4100 

PROCCN 

Processor  generically  modeled 

4500 

PROCEX 

Processor  explicitly  modeled 

5000 

MEMCK 

Memory  event  state  change  rules 

5500 

MEMEX 

Memory  explicitly  modelled 

6000 

COMCK 

Communication  event  state  change  rules 

6100 

COMGN 

Communication  generically  modeled 

(.500 

COM  EX 

Communication  explicitly  modeled 

7000 

EXTDCK 

External  device  event  state  change  rules 

7100 

EXTDGN 

External  device  genericallv  modeled 

7500 

EXTDEX 

External  device  explicitly  modeled 

Statistical  Collection  Summary 

8000 

STATCL 

Statistical  collection  update 

8100 

ST.4TPS 

Periodic  summary 

8200 

STATGS 

Global  statistical  summary 

8300 

STATRS 

Statistica  Reset 

End  of  Simulation  Processing 

9000 

F.NDSM 

End  Simulation 

4.4. 1  Data  Rase  I/O.  Prior  to  functional  simulation  the  initialization  step  involves  both  manual  and 
automated  process  (preferably  interactive)  steps  to  collect,  formal,  sort,  and  merge  appropriate  data 
inputs.  Detailed  design  of  these  steps  requires  that  the  specific  evaluation  environment  objectives  and 
existing  data  collection  formats  be  studied.  From  this  study,  automated  processing  for  interfacing, 
converting,  and/or  additional  collecting  of  inputs  can  be  designed  and  implemented  for  a  given  evaluation 
organization.  The  input  parameters  and  forms  described  in  Section  4.3  provide  a  starting  point  as  to  the 
hierarchical  categories  of  a  data  base  which  address  the  basic  generic  multiple  processor  configuration  as 
applied  to  a  given  real-time  flight  training  application  environment. 


57 


The  end  simulation  report  generator  design  features  are  also  greatly  influeneed  bv  the  data  base 
strueture.  as  vvell  as.  the  evaluation  environment.  The  major  advantage  of  an  independent  report 
generator  (over  built-in  standard  set  of  simulation  run  reports)  is  that  it  ean  be  used  at  any  time  after  the 
run  to  generate  selective  reports  as  needed.  For  example,  if  a  memory  romponent  is  flagged  as  a 
bottleneck,  the  memory  processor  communications  report  for  the  suspect  memory  can  be  requested  for 
further  details  to  help  identifv  the  storage/retrieval  blocks  in  demand.  By  utilizing  an  interactive  multi 
terminal  report  generator  process,  several  evaluators  could  be  addressing  separate  aspects  of  the 
alternative  candidate  design  configurations  under  evaluation. 

This  centralized  design  repository  concept  for  I/O.  if  properly  implemented,  facilitates  configuration 
management  and.  in  turn,  the  resulting  analysis  integrity  associated  with  comparative  and  related 
tradeoffs  is  of  higher  quality.  Care  should  be  taken  in  polling  the  potential  users  of  the  system  prior  to 
selection  and  detail  design  of  the  automated  repository  tools  to  be  implemented.  Commercially  available 
data  base  systems  have  many  features  which  should  not  be  overlooked.  As  a  minimum  the  following 
features  should  be  addressed: 

1.  Collection  sources  and  formats 

2.  Volume  and  frequency  of  data  I/O 

3.  Security  provisions 

4.  Configuration  management  controls 

5.  Backup  recovery  from  system  failure 

(>.  Data  accessibility  via  multiple  users  and  programs 

7.  Hierarchical  and  relational  storage/retrieval 

8.  Report  generation  features. 

The  current  functional  simulator  languages  do  not  provide  these  features.  For  this  reason,  most  of  them 
operate  in  a  batch  mode  or  a  customed  interactive  environment  which  incorporates  voluminous  pre- 
formatted  files.  The  automated  data  base  area  is  one  recommended  for  further  study. 

Figure  33  illustrates  the  segmented  data  base  structures  which  have  been  designed  to  interface  with 
both  CPPS  (block  10)  and  the  Partitioning  Algorithm  for  Software  Systems  (block  '))  under  given 
evaluator  (block  3)  run  requests.  The  left  hand  side  represents  the  flight  simulation  requirements, 
baseline  load,  technology  and  candidate  design  SW/HW  definitions.  The  right  hand  boxes  represent 
outputs  which  are  available  to  the  evaluator  during  the  iterative  process  of  computational  partitioning  and 
performance  prediction  evaluation.  This  study  has  concentrated  on  the  performance  prediction  tool. 
Reference  7  relates  design  details  applicable  to  the  partitioning  evaluation  tool.  A  good  data  base  structure 
will  greatly  facilitate  a  structured,  well  organized  set  of  evaluation  tools. 

4.4.2  Simulation  Control.  Discrete  event  simulations  are  controlled  and  driven  by  discrete  time 
tagged  events.  An  event  calendar  permits  a  centralized  mechanism  for  posting  of  events  and  determining 
the  next  event  to  be  processed.  A  set  of  event  handling  rules  should  include  the  ability  to: 

1.  Support  parallel  events  (more  than  one  activity  model  for  a  particular  time  line  instance). 

2.  Recognize  and  avoid  duplicate  postings  of  a  redundant  type  (identical)  event  for  the  same 
time. 

3.  Permit  a  priority  scheme  for  event  execution  selection  for  events  which  occur  at  the  same 
time. 

4.  Permit  an  event  which  is  currently  posted  to  be  rescheduled  or  deleted. 

5.  Utilize  a  dynamic  memory  management  scheme  for  maintenance  of  the  event  calendar  and 
user  dynamic  files. 
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higure  33.  Relationship  of  partitioning  and  simulation  models. 


6.  Maintain  at  least  four  event  attributes  (one  of  which  keys  the  specific  event)  which  may  be 
either  real  and/or  fixed  dependent  upon  event  definition. 

7.  Accommodate  space  to  handle  at  least  1000  events  at  any  point  in  the  simulation. 

8.  Permit  interface  to  user  supplied  event  code  to  model  the  event. 

0.  Access  to  complete  source  code  listing  of  any  and  all  event  calendar  simulation  code  to  be 
incorporated  in  actual  implementation. 

10.  Provide  debug  mechanisms  for  event  trace  prinlouts/displays  as  a  function  of  user  supplied 
simulated  time  intervals  of  interest. 

It  should  be  noted  that  both  CASP  and  MODLER  support  most  of  these  features  when  the  user  supplied 
model  code  adheres  to  certain  coding  conventions  inherent  to  the  respective  host  simulation  language. 

The  models  to  carry  out  the  computations  for  performance  prediction  of  a  candidate  flight  training 
simulator  computational  subsystem  design  are  illustrated  in  Figure  34.  These  models  are  under  the  control 
of  a  discrete  event  simulation  event  calendar  as  defined  in  this  subsection.  The  application  models  include 
the  external  I/O  load/response  events,  data  block  models,  and  task  models.  The  hardware  configuration 
models  include  the  memory  access  management  events;  processor  operating  system  and  task  service 
events;  and  the  communication  rules  models  and  events.  Statistical  collection  models  and  events  interface 
with  application  and  configuration  models  to  collect  queuing  and  timing  statistics. 
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Figure  34.  Discrete  events  in  the  model  include  external  I/O 
load/response,  memory  access  management,  processor 
operating  system  and  task  servicing,  and  communication 
rules  which  are  driven  by  candidate  design  attributes 
for  the  load,  components,  data,  task  and  communication  flow. 


The  basic  event  scenario  for  the  generic  multiple  processor  is  one  of  data  arrival  and/or  time 
triggered  task  entries  which  require  service  by  communication  and  processor  devices.  The  respective 
devices  are  then  busy  for  a  given  period  of  time.  At  the  end  of  this  time  period  a  response  and/or  other 
events  are  generated.  The  device  becomes  idle  if  no  other  entries  have  been  placed  in  its  queue  waiting  to 
be  serviced.  Each  of  the  major  events  is  further  described  under  its  specific  functional  relationship  with 
the  performance  predictor  simulator. 

4.4.3  Real-Time  Computational  Application  Models  and  Extents.  The  real-time  computational 
subsystem  is  characterized  via  a  baseline  load  which  is  serviced  via  data  queuing  and  predefined 
processing  tasks.  The  cyclic  nature  of  the  flight  training  simulator  computational  tasks  facilitates  load 
initiation  and  task  tracking  events.  The  inputs  described  in  Section  4.3.2  and  4.3.3  provide  the  basic 
computational  task  design  and  load  parameters  from  which  task  flow  may  be  simulated. 
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The  basic  load  may  be  likened  lo  a  pulse  generator.  A  given  load  is  referenced  as  a  master  activity 
sequence  such  as  cockpit  A  computational  flow  during  takeoff.  Another  master  sequence  might  represent 
enroute  flight  configuration  computational  mix  and  yet  another  for  air-to-air  combat  engagement.  The 
start  and  stop  times  provide  a  means  to  vary  the  training  mix  activities  with  respect  to  time  for  each 
training  station  to  be  serviced  by  the  candidate  computational  system  design.  The  input  load/flow 


parameters  provide  the  following  discrete  events: 

1.  Master  activity  start/stop. 

2.  Cycle/thread  initiate,  data  track,  complete,  repeat  if  cyclic. 

3.  External  data  queue/buffer  record  generation  input/output. 

The  major  emphasis  in  determining  performance  is  on  data  flow  and  throughput.  Figure  35  illustrates  the 
discrete  application  events  with  respect  to  data/task  flow.  Cycle  and  thread  definitions  are  designed  to  act 
as  a  feedback  mechanism  for  pulse  arrivals. 
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Figure  .35.  Data/Task  enablement  pulse  flow  through  system 
states  of  generation,  arrival,  leave  queue,  and  exit. 


The  word  task  queue  is  utilized  to  distinguish  that  the  type  of  data  block  being  modeled  is  related  to 
task  load  enablement.  It  may  represent  a  physical  data  queue  block  in  memory  or  a  time  triggered 
processor  task  enablement  mechanism.  Any  and  all  data  blocks  to  be  communicated  among  the 
application  tasks  and/or  from  external  devices  are  defined  via  the  user  candidate  design  Group  4  inputs 
(Section  4.3.2).  Simulation  models  of  data  flow  for  each  of  the  data  block  disciplines  (FIFO.  LIFO, 
Circular  buffer,  sequential,  random  etc.)  permits  timing  and  sizing  computations  to  be  made  taking  the 
type  of  I/O  and  communication  device  into  consideration.  These  are  support  models  which  are  utilized  by 
event  logic  steps  when  modelling  data  flow.  Random  number  generated  distribution  models  for 
probabilistic  data  paths  are  also  incorporated  to  provide  parametric  timing  sensitivity  studies. 


Specific  task  resource  requirements  are  handled  via  model  task  allocation  inputs  of  the  candidate 
design  Croup  5  (Section  4.3.2).  These  attributes  are  used  to  define  the  scheduling  levels  and  schedule 
states  applicable  to  each  processor  and  to  trace  the  simulation  from  the  application  viewpoint  to  collect 
appropriate  statistics  for  tasks,  cycles,  and  threads.  These  attributes  and  models  are  utilized  as  needed  by 
the  major  configuration  events.  For  example,  if  Task  T  is  to  execute  on  processor  P,  the  time  for  its 
completion  is  computed  as  a  function  of  task  T’s  description  and  processor  P's  technology  data  base 
statistics.  Communication  models  are  referenced  to  obtain  I/O  execution  times  for  task  communication. 
We  now  describe  the  candidate  configuration  events. 

4.4.4  Candidate  Configuration  Hardware  Models  and  Events.  The  candidate  configuration  models 
include  processors,  memories,  communication,  and  external  device  models.  As  denoted  in  Table  8  design 
provisions  have  been  made  for  device  state  rules  and  state  transition  with  both  generic  and/or  user 
supplied  models  of  a  given  device.  Each  of  the  four  generic  devices  is  briefly  described. 

The  processor  event  models  are  designed  to  facilitate  a  variety  of  architectures  and  operating  system 
features  to  include  the  following: 

1.  Priority  and/or  circular  scheduling  of  time  enabled,  data  enabled,  and/or  slaved  tasks  on  a 
given  real-time  schedule  loop  (such  as  frame,  sub-cycle,  cycle,  batch  etc.)  is  modelled. 

2.  Multitasking  of  at  least  four  scheduling  level  task  loops  incorporating  I/O  interleaving  and 
scheduling  level  discipline  rules  is  modelled. 

3.  Task  I/O  interrupts  are  interfaced  with  communication  events  to  determine  service  delay  time 
for  resumption  of  task  as  a  function  of  the  required  processor,  data  block,  and  device 
communication  attribute. 

4.  Statistics  based  on  processor  utilization  events  are  to  be  collected  for  use  in  reports  as 
described  in  4.2. 

Design  efforts  placed  emphasis  upon  generic  processor  operating  system  features.  Simulation 
mechanisms  were  studied  for  modelling  of  the  various  discrete  processor  states  to  include  task 
enablement,  task  execution,  and  task  interrupt  handling  procedures.  As  a  result  of  this  design  analysis, 
additional  processor  technology  and  baseline  application  input  parameters  were  identified.  The 
technology  parameters  (Table  B-5  Appendix  B)  identified  relate  directly  to  the  level  of  multitasking  and 
means  for  introducing  and  invoking  tasks  in  a  multiple  processor  environment.  These  parameters  relate  to 
operating  system  selection  and  customed  application  real-time  executive  controls. 

The  simulation  performance  models  studied  tend  to  lump  application  execution  resources  and 
operating  system  overhead  together.  This  technique  is  appropriate  for  a  distributed  executive  when  the 
application  tasks  utilize  the  same  processor  as  the  decision  making  process.  However,  in  instances  where  a 
master/slave  scheme  is  utilized  the  application  tasks  are  not  run  on  the  same  processor  as  the  executive 
controlling  processor.  In  this  latter  instance  there  is  a  need  to  decouple  the  task  enablement  decision 
making  processes  from  the  application  task.  The  multiple  processor  model  provides  a  means  to  define 
both  distributed  executives  and  masler/slave  executive  processing  disciplines.  It  basically  requires  the 
executive  task(s)  be  included  as  separate  task  definitions.  This  is  most  important  in  the  master/slave 
configurations. 

Design  emphasis  was  also  placed  on  algorithms  for  modelling  multiple-processor  relationships  with 
shared  memory.  The  increasing  utilization  of  multiport  memories,  memory  mapping,  and  communication 
bases  has  facilitated  additional  memory  capacities  and  interprocessor  communication  alternatives  for  user 
applications. 
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These  features  simplify  user  application  code  interfaces  but  carry  with  them  additional  operating 
system  and  communication  resource  management  overhead.  One  critical  aspect  is  the  detection, 
prevention,  and/or  resolution  of  deadlock  situations.  This  is  the  case  when  two  processes  are  waiting  for 
access  to  a  resource  currently  dedicated  to  the  other  process.  In  this  case  neither  can  proceed  without  an 
arbitrator  which  can  suspend  one  of  the  processes  and  properly  redo  resource  assignments  with 
appropriate  data  integrity  controls  for  the  given  application.  The  processor  models  designed  for  the 
performance  predictor  algorithm  includes  a  means  for  detecting  deadlock  situations.  This  is  basically  done 
by  the  memory  model  status  and  wait  time  exceeded  indicators.  The  model  could  also  incorporate  various 
analytic  algorithms  for  bottleneck  detection  to  support  more  detailed  analysis  of  shared  resource  benefits 
and  shortcomings. 

There  are  basically  two  memory  management  events:  access  request  made  and  access  request 
complete.  The  access  request  utilizes  current  memory  state  and  data  block  read/write  access  request 
information  to  compute  delay  before  data  access  will  be  completed.  A  request  complete  event  is  posted  for 
the  time  in  which  the  data  will  be  made  available  to  the  requesting  processor  or  peripheral.  These  events 
will  be  applicable  to  each  memory  device  in  the  design  configuration  and  also  serve  to  collect  memory 
utilization  statistics. 

To  properly  relate  memory /processor  external  device/processor,  processor/processor,  and  external 
device/memory  communications,  communication  models  and  events  are  necessary  to  close  the  loop.  These 
models  permit  the  rules  of  the  candidate  computational  subsystem  to  be  modeled  and  evaluated.  This 
particular  area  has  been  selected  for  further  analysis  as  to  ascertaining  the  critical  performance  features 
which  should  be  modeled  and  measured  for  both  the  full  operational  design  and  the  impact  of  devices 
which  may  be  temporarily  out  or  off-line.  As  a  minimum  the  simulation  model  should  account  and 
readjust  multiple  communication  requests  for  the  same  transmission  link  to  the  predetermined  sequential 
order  via  the  configuration  rules.  This  is  to  include  check  for  target  device  availability  as  well  as 
communication  component  utilization  statistics  of  wait.  busy,  and  idle  states. 

4.4.5  Statistical  Distribution  and  Collection  Models  and  Events.  A  major  aspect  of  discrete  event 
simulation  is  the  means  for  setting  up.  updating,  and  reporting  statistical  measures  for  a  variety  of 
parameters.  Statistical  collection  is  greatly  simplified  if  a  set  of  standard  generalized  routines  are  available 
for  basic  parametric  statistics,  time  utilization  statistics,  histogram  statistics,  and  special  distribution 
computations.  Basic  statistics  include  number  of  observations  made.  mean,  standard  deviation,  maximum 
observed,  and  minimum  observed  values  for  given  user  specified  parameters.  Time  utilization  is  based  on 
zero-one  status  summed  over  a  given  time  interval;  thus,  it  represents  the  length  of  time  spent  on  a  given 
stale  such  as  busy  (one)  versus  idle  (zero)  time.  Histograms  keep  track  of  the  observed  value  distribution 
in  terms  of  a  finite  number  of  intervals  which  generally  denote  a  unit  of  time  for  which  the  observation  is 
made.  Special  distributions  (such  as  uniform,  normal,  exponential,  gamma,  poisson.  etc.)  permit 
parameterization  of  modeling  decision  steps  as  well  as  special  output  report  computations.  Both  GASP  and 
MODELER  provide  for  statistical  data  collection  and  reduction. 

4.4.6  Final  Design  l\otes.  The  generic  multiple  processor  model,  as  defined  by  this  study,  must 
contend  with  an  ever  changing  environment  of  alternatives.  The  complexity  of  the  communication 
modeling  alternatives  was  recognized  early  in  the  contract  as  requiring  more  study  than  alloted  time  and 
resources  could  permit.  As  a  result  the  design  details  and  manual  demonstration  problem  as  presented  in 
this  report  had  to  be  kept  at  a  fairly  high  overview  level.  A  more  rigorous  design  and  demonstration  are 
possible  given  more  analysis  time  and  resources. 


5.  SI  MMAHY 


5.1  Findings 

The  ultimate  test  of  a  design  is  to  build  a  prototype  to  see  if  it  indeed  works.  This  is  an  expensive  step 
which  may  encounter  design  flaws  in  the  process  of  debugging  the  design  implementation  causing  time 
delays  due  to  design  alterations  in  both  hardware  and  software.  This  study  has  pursued  techniques  for 
design  evaluation  analysis  prior  to  its  prototy  pe  implementation.  In  particular  the  candidate  configuration 
task  activity  time  line  with  respect  to  resource  management,  communication,  and  operational  rules  has 
been  stressed. 

The  flight  training  environment  is  one  of  dy  namic  changing  loads  which  reflect  current  training  job 
mix  in  progress.  Ortaiu  job  mix  capabilities  are  naturally  more  stressing  than  others.  For  advanced 
training  configurations  (with  multiple  crew  training  stations  and  instructor  stations)  enumeration  of  all 
possible  job  mix  states  ma\  he  an  enormous  if  not  impossible  undertaking  in  itself.  However, 
identification  of  the  tasks  required  to  support  a  given  required  training  capability  is  an  essential  feature 
which  must  be  traceable  to  and  accounted  for  bv  am  viable  candidate  design  in  terms  of  a  representative 
demonstration  which  provides  traceability  of  all  systems  inputs  through  respective  task  processes 
necessary  to  obtain  the  resultant  system  responses. 

In  the  multiple  processor  environment  manual  demonstrations  of  the  design  for  particular 
capabilities  is  time  consuming,  error  prone,  and  often  too  bulky  to  look  at  all  the  intricate  details.  Two 
automated  techniques  may  he  employed,  namely  ,  algorithm  emulation  and  system  simulation.  Emulation 
requires  that  a  machine  level  model  he  available  to  represent  the  target  processor  and  the  environment  in 
which  it  is  to  operate  including  the  actual  software  object  code  and  realistic  sample  input  data  to  be 
processed.  This  is  a  good  technique  for  benchmarking  of  algorithms  for  hardware  which  is  on  the  design 
drawing  board  but  not  vet  available.  However,  it  is  not  suitable  for  evaluation  of  the  total  system  design 
and  internal  system  configuration  interactions  from  a  multiple  processor  system  design  evaluation  point  of 
view.  A  system  simulation  of  the  design  components  for  given  baseline  loads  is  the  only  viable  alternative 
for  evaluating  the  candidate  design  in  terms  of  timing  and  data  flow  for  a  proposed  operational  training 
simulator  system  prior  to  prototype  availability. 

Many  types  of  system  simulations  exist,  but  in  most  cases  they  address  specific  rather  than  generic 
models  making  them  good  tools  for  a  given  project  but  very  inflexible  and  unappropriate  for  use  with 
other  projects.  One  reason  is  the  lack  of  standard  rigorous  design  notation.  A  second  reason  is  the  use  of 
cus'tomi/.ed  assumptions  which  are  built  into  the  modeling  terminology  definitions  and  output 
interpretation  for  a  given  project.  In  many  rases  these  design  model  simulations  are  products  of  the 
designer  developing  the  actual  system  and  the  benefits  of  independent  evaluation  are  not  obtained. 

The  resultant  evaluation  model  design  derived  by  this  study  is  a  generic  multiple  processor  candidate 
configuration  simulation  which  is  independent  of  any  specific  system  with  regard  to  processor,  memory, 
and  communication  models.  It  is  driven  and  based  upon  data  which  reflects  a  complete  design  for  a  given 
candidate  under  evaluation  including  the  software  task  relationships  for  given  baseline  evaluation  loads. 
The  model  (described  in  Section  4)  includes  automated  proress  steps  for  data  base  inpul/output 
management  necessary  to  support  detailed  and  quirk  look  evaluation  analysis. 
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^■2  Recommendations 


Two  areas  requiring  further  study  and  analysis  were  identified.  These  are: 

1.  Communication  technology  and  design  reliability  alternatives. 

2.  Automated  flight  training  simulator  candidate  design  data  base  repository. 

These  two  areas  relate  directly  to  the  level  of  simulator  fidelity  and  feasibility  of  its  use  as  a  standard 
design  evaluation  tool. 

To  carry  out  these  studies,  it  is  recommended  that  a  specific  Air  Force  Agency  (which  is  responsible 
for  flight  training  computational  design  evaluations)  sponsor  a  prototype  implementation  of  the 
functional  simulation  model.  Details  of  the  communication  and  data  base  tasks  would  constitute  the  first 
phase  of  the  recommended  effort  to  delineate  the  complete  detail  design  for  the  sponsor  agency.  The 
second  phase,  upon  approval  of  Phase  I.  would  be  used  to  automate,  test  and  verify  the  design. 
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APPENDIX  A:  FUNCTIONAL  PERFORMANCE  SIMULATOR 
OUTPUT  DEFINITIONS 


67 


PAOS  B LAMK-MO*  Fll>® 


DEALS  SEC  I  OPT  -7  PACE 


DEALS 


OATE  3 -AUG -7*  ID  DEALS  SEC  IOPT-7  PACE 


DEALS  SEC  IOPT-7  PAGE 


DEALS 


DATE  3 -AUG -79  ID  DEALS  SEC  I  OFT -7  PACE 


SSUE  1  DATE  3-AUC-79  ID  DEALS  SEC  IOPT-7  PACE 


SSUE  I  DATE  14-AUC-79  ID  DEALS  SEC  IOPT-7  PACE 


L 


APPENDIX  B:  FUNCTIONAL  PERFORMANCE  SIMULATOR 
INPUT  DEFINITIONS 


77 


33UE  I  DATE  27- NOV-79  ID  DEALS  SEC  IOPT-I  PACE 


S3UE  1  DATE  Z7-MOV-79  ID  DEALS  8EC  IOPT-t  PACE 


DATE  27- NOV-79  ID  DEALS  SEC  IOPT-1  PACE 


sur  I  DATE  14-  AUG  -  79  ID  DEALS  SEC  IOPT-9  PAGE 


PARAMETER  NAME  ! MNEMONIC  VALUES  UNITS/VALUE  MEANING 


i  C 
C  -  0 

9  ml 

-  C  A 

«  • 

■  "0  +> 

V  -  *•* 

A  9 

0  •  V  -» 

V  V  C 

0  0  •  k 

S  V  C  0 

-  0 

v  ■o  a  l 

«  C  f  I 

3  0  0  - 

£  0  0 


C  «*» 

9  9 


•  k 

V  0 

£ 

0  •  ml 

+>  4*  C 

0  0  0 

I  ■o  c 

-  0  M 

mi  v  a  c 

*  C  £  0 

3  0  0  mi 

C  0  W  £ 


W 

z 


Q  Q 


a  a 
<  < 


7 

(0 


9  * 
A  0 

V 

* 

t  - 

•» 

9  C 

w  0 
£ 
-  4* 

0 

A  • 

0  k 
«<  0 
(9  E 


*  ? 

«  • 

0  3 

4i  0 
•) 

c  t 

0  A 

0  mi 
• 
3 

->  S 
o 

u  +> 
0  3 
-J  A 


A 

U  C 
ml  9 
0  9 

k  - 

0  9 


0  0 


0 

a  o  * 

i  9  * 
*1-0 
v-  0  v 


i 

} 

!  . 

m 

i 

i 

U 

k 

k 

i. 

• 

• 

• 

• 

1  4i 

V 

*» 

*> 

0 

u 

0 

0 

0 

0 

0 

0 

0 

u 

u 

k 

c 

k 

0 

0 

0 

0 

0 

• 

. 

£ 

£ 

A 

£ 

A 

<3 

>-  i 

1  u 

0 

0 

• 

u 

• 

e 

u 

■ 

u 

u 

{  A 

-1 - 

A 

A 

e 

! 

< 

ft. 


A 

o 


1 

** 

ms 

** 

ms 

J 

• 

M 

*• 

A 

A 

• 

• 

w 

w 

1  o 

1  c 

C 

-l 

O 

> 

pm 

u 

* 

u 

• 

M 

ml 

j 

1  u 

•• 

u 

«• 

a 

a 

I  * 

W 

< 

w 

< 

< 

1 

1 

;  *■ 

,  N 

r* 

i  (3 

a 

a 

1 

* 

z 

z 

j 

< 

< 

* 

< 

M 

M 

e 

M 

— 

ft 

0 

C 

-> 

• 

z 

i  *-» 

7 

k 

A 

V 

< 

0) 

k 

Ik 

K 

7 

0 

U 

Ik 

• 

k 

*0 

o 

»- 

z 

■» 

0 

c 

ml 

3 

o 

t 

0 

a 

a 

«* 

1 

0 

»»* 

V- 

ml 

k 

0 

< 

QC 

< 

c 

9 

A 

(/) 

H 

u 

• 

3 

< 

c 

*0 

t 

! 

0 

< 

j 

- 

ml 

iu 

i 

3 

« 

C* 

«■ 

84 


OEALS  SEC  lOPT-y  PAGE 


ISSUE  1  DATE  1 4  -  AUG  -  79  ID  DEALS  SEC  IOPT 


ISSUE  1  DATE  I4-AUG-79  ID  DEALS  SEC  IOPT-9  PACE 


PACE 


SEC  I OPT  - 9  PAGE 


Table  B-3.  Baseline  Load  Parameters 


HI 

i 


N 


I 

0. 

Q 


j 

j 


U 

hi 

10 


•) 

-J 

< 

hi 

Q 


Q 


N 

( 

2 

< 

i 

* 


< 

Q 


<n 

w 


91 


S3UE  1  DATE  I4-AUG-P9  IO  DEALS  SEC  tOPT-IZ  PACE 


DATE  3-AUG-79  ID  DEALS  SEC  IOPT-IZ  PAGE 


DEALS 


ISSUE  |  OATE  3-AUG-79 


F/6  9/2 


AD-A101  919  TELEDYNE  BROWN  ENGINEERING  HUNTSVILLE  AL  SYSTEMS  DIV 
ADVANCED  MULTIPLE  PROCESSOR  CONFIGURATION  STUDY. (U) 

NAT  81  S  J  CLYMER  F3361S-T9-C-0003 

UNCLASSIFIED  AFHRL-TR-SO-43  NL 

2  --  s 


AD.  a  1  4 


issue 


DEALS 


8SUC  1  OATE  14 -AUG- 79  ID  DEALS  SEC  IOPT- 


9  L  W 

•  19  1 

9  > 

a  k  e  • 

0  0  0  -J 

e 

C  •  9  • 

•  -■JO- 

»■  9  a  -  a 

o  c  *  >  c 

•  0  •  • 

«  y  o  i-  o 

■jo  a  c 

•  o  c  « 

>  o  w  a 

•  c  a  j  • 

.J  -  3  0  9 


-»  CO 

•  r 

-J  a 

0  to 

-  9  - 

«*  -  9 

c  9  • 

•  1  0  -* 

3  0  •  •  A 

9  9  C  t  0 

•  o  re 
(0  e  <  v  • 


<*  o  j 

4»  9  *  j  ) 

-or-  > 

•  -»  j  c  • 

j  a  o  c  o  j 

•  *  •  0  0  - 

>  9  •  -  b  *0 

•  9  o  w  j  a  o  • 

w  c  a  C  9  $  *> 

o  ^  -i  9  t  e 

t  9  i.9  a  *-  r  • 

•  •  0  c  t.  f  a  J  I 

r  j  a  -  •  o  *  • 

j  y  f  •  r  a  «  c  -» 

o  •  s  r  j  •  •  r 

-  r  0  4  0  9  0 

0  -  •  S  J  0  -  c 

so  <  -  o  -  e  9  • 


at  -* 

-  4  •  .  « 

O  !>■  - 

o  o  a.  < 

o  J  0  4  s  H 

•  e  *  ox 

^  •  4  •  J  K 

r  f  o  r  w  j 

J  ■  -w  -w 

e  r  j  c 

-ooo 

e  j 

•*  •  «*  9  ~ 

•  0  «  J 

>  tf  W  U  • 

•  4  0  0  3 

«J  o  a  <j  • 

•  *  ~  a  •* 


r  3 

e  -» 

o  i  *> 

J  U  u  |  o 

t-  •  •  -  •  I 

o  ft  4  o  *-  r 

a  o  e  -  o 

£  *>  t  i.  o  • 

-  j  o  •  •  e  i 

o  e  w  r  - 

4  r  v  4 

-440-k- 

-  r  o  o  r 

-j  •  j  • 

-  J  O  O  -  7  - 

0  0  •  .J  -»  9  | 

kC«J««<C4 
•  L  J  H  o  -  - 

>or-jo4e 


ISSUE  1  DATE  14-  AUG  -  79  ID  DEALS  SEC  IOPT-12  PACE 


mvA  3i HOW3HW  l  suvN  aaiauvavd 


ISSUE  1  DATE  27  -  MOV- 7*  ID  DEALS  SCC  IOPT-3  PACE 


PAftAMCTEI  MAtIC  MNEMONIC  |  VALUES  |  UNITS/VALUE  MEANING 


-J  ^  «l 


O  Q  O  Q  Q  Q 
IflBflflO 
u  u  u  u  u  u 
H  H  H  H 


Q 

fl 

U 

H 


U 


A 

O 


HHHKh- 
0  0  0  0  2) 

U  U  U  U  U 

K  H  H  ►»  H- 


DATE  Z7-NOV-79  ID  DEALS  SEC  IOPT-9  PAGE 


OA7E  2S-DEC-79  ID  DEALS  SEC  IOPT-S  PAGE 


DEALS 


SSUE  1  DATE  21  -DEC-79  IP  DEALS  SEC  IOPT-S  PAGE 


DEALS 


DEALS 


SSUE  1  OATE 


0  C  0  4  A 

fl  •  c  o  f 

O  o  • 

4  -  «  «  L  « 

k  k  C  •»  - 

I  fi  •  0  1 

3  e  *>  -j  •  k 

a  i.  o  o  £  9  * 

0  0  -*  * 

k  k  w  k  »*  0  V 

o  o  a  o->o 

x  »  u  x 

o  -  a  •  •  • 

I  *  i  *  -- 

B  3  -  ®  3  3  - 

N  i  «*  N  §  •  *» 


on  a  £ 

f  o  I  y 

0  • 

4  *  k  4  9 

k  6  ^  -  4* 

0  0  S  - 

W  -»  0  k  -* 

U  9  3  I  0 

0  -«  £  3 

k  »  o  o 

0-300 
X 

0  »  0  0  | 

1  I  -»  k 

■  3  3  -  0 

(M  *  4  •  » 


-  k 

X  I  o 

0  4  a 

lot 
0  0 

4  *  C  4 

k  c  ^  - 

0  0  S 

4*  W  0  k 

o  a  3  o 

0  W  X 

k  <te  0  4* 

0-30 

X 

0*00 

.!  §; 
N  1  4  ♦ 


9  3 
1  19 


4 

4 

4 

4 

k 

k 

k 

k 

i  • 

0 

0 

0 

4* 

V 

V 

4» 

0 

0 

0 

0 

1  0 

0 

0 

0 

k 

k 

k 

k 

0 

0 

0 

0 

X 

X 

X 

X 

0 

0 

0 

0 

u 

-1 

M 

-1 

0 

or 

fl 

u 

•4 

*4 

►4 

■4 

- 

Itf 

ia 

_ “ _ 

4*  0  4# 

c  *>  oe 

0  O  4#  0 

f  *0  C  0  c 

0  0  0  -0 

k  4  k  k 

-  3  4»  a  - 

3  3  0  3 

o  k  a  k  9 

o  o  4»  a  o  o 

k  -  3  a  k  «* 

*4  o  0  o 

f  -  *  O 

0  4»  j  X  0 

V  C  9  y  4J  • 

9  0  0  0  9  - 

0  <4 


0 

e  y  o 
a  o  w 
-  o  c  o 

4  0  0  - 
0  4  k 

o  3  4»  a 

3  0 

o  k  a  k 
4»  o  *>  a 
o  -  3  a 
o»-oo 

O  4»  -*  X 
0  6  0  0 
6  •  X  *» 
0  0  3  0 

U  -  --  4. 


DATE  l A • AUG - 79  ID  DEALS  Sec  IOPT-14  PACE 


J 

i 

X 

M 

9 

• 

M 

c 

1 

k 

■m 

P 

4 

N 

X 

« 

0 

0 

0 

0 

< 

d 

a 

k 

• 

9 

a 

< 

U 1 

d 

1 

• 

• 

n 

k 

>- 

c 

■k 

c 

a 

d 

£ 

a 

c 

0 

a 

«•» 

9 

a 

d 

0 

o 

Ul 

3 

mm 

a 

3 

M 

3 

d 

£ 

d 

0 

£ 

k 

J 

k 

0 

0 

e 

c 

k 

0 

• 

P 

« 

0 

u 

V 

• 

• 

— 

9 

d 

•m 

0 

> 

• 

— 

0 

p 

> 

0 

«■» 

0 

a 

\ 

9 

c 

1 

« 

9 

s 

• 

-t 

« 

• 

k 

3 

9 

1 

mi 

a 

U 

0 

f 

d 

d 

0 

h» 

V 

c 

• 

3 

M 

0 

c 

i 

• 

e 

k 

ft. 

9 

9 

c 

0 

z 

k 

• 

0 

3 

• 

0 

c 

0 

3 

p 

— 

k 

= 

ft. 

c 

u 

c 

e 

- 

M 

C 

- 

-> 

9 

a  * 

4 

a  - 

k 

Id  Id 

k 

■ 

•  • 

U  -l 

9 

mi 

Ul  *• 

d 

0 

(3  -i 

(1 

0 

P 

k 

0 

•• 

t  - 

• 

• 

k 

• 

k 

c 

'  3 

c 

d 

0 

% 

9 

0 

0 

1  ** 

c 

u 

£ 

n 

• 

£ 

i 

• 

• 

a 

« 

d 

0 

9 

!  > 

■ 

■ 

* 

e 

c 

1 

<0 

ik 

M 

•0 

S 

u 

*4 

o 

0 

/■* 

z 

w 

JC 

o 

*4 

Ik 

w 

c 

u 

O 

K 

M 

ul  ! 

(0 

0) 

z 

* 

* 

0/ 

a 

M 

c  ! 

1  Ul 

Ul 

Ul 

id 

■ 

d 

9 

C 

VI 

P  1 

9 

0 

c  < 

* 

a 

9  - 

u 

I 

4 

<  4 

C 

0  V 

« 

1  d 

d 

d  1 

z 

c 

e 

1  4 

9 

9 

P  - 

Of 

C 

e 

e  i 

Ul 

0 

e 

k 

9  1 

►» 

a 

a 

0 

Ul 

i  u 

f 

d 

P  1 

c 

o  • 

0 

0 

0  1 

< 

u  - 

a 

0 

9  - 

a 

1  ♦ 

* 

<k 

k  1 

< 

£  • 

a 

i 

H  4 

0 

m 

d 

X 

4 

X 

P 

4 

at 

0 

— 

P 

Ul 

1  9 

0 

tarf 

k 

0 

9 

>  £ 

d 

k 

1  d 

0 

P 

£ 

k 

p 

9 

d 

9 

i  *» 

d 

'  0 

£ 

U 

£ 

«•» 

SSUt  OATE  1 4  -  AUG  -  79  ID  DEALS  SEC  IOPT-14  PAGE 


PARAMETER  NAME  MNEMONIC  VALUES  UNITS/VALUE  MEAN 


EC 


